## Details | Date | Change | Details | |-------------------------------|-----------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | November 22, 2022 | Deprecation of `POST /searches` | The generic search API will be deprecated in favor of `POST /inputs/searches` and `POST /annotations/searches`. `POST /searches` will still be supported for now, but will not receive any feature updates so users are suggested to use the newer search endpoints. | | January 20, 2022 | Deprecation of `name` and `display_name` | To make Clarifai Model IDs more readable and user friendly, we plan to make the following API/UI changes during the week of Jan 17th. The old `user_unique_id` will still be usable in all queries, but the responses will be filled with the new `v2_user_unique_id`. `name` and `display_name` are deprecated in the API and UI, and `user_unique_id` will soon be deprecated as well so users are suggested to use new model id field `v2_user_unique_id`. | | November 24, 2021. 9:00am ET | Deprecation of type option | The `type` option in POST /models and /models/searches request will no longer be supported and will be removed from our API after this point in time. `model_type_id` is in use for model type references. | | February 12, 2021. 9:00am ET | Deprecation of `delete_all` option | The `delete_all` option in DELETE /inputs request will no longer be supported and will be removed from our API after this point in time. You can delete inputs by id. Each request can have at most 128 ids. | | October 16, 2020. 9:00am ET | Deprecation of Demographics Model | To reduce the risk of race bias in our own models, we have constructed a new approach to visual recognition of race. We've also divided age, race and gender recognition into separate models, and then packaged the models into a new public Demographics Workflow. This new approach provides much more flexibility, and makes outputs easier to parse. We will be retiring the current demographics model on October 16th, 2020. Please reference this [blog post](/content/blog/new-demographics-workflow/index.html) and our [API documentation](https://docs.clarifai.com/api-guide/api-overview) for more information about how you can update your code to take advantage of the new workflow. | | October 20, 2020. 9:00am ET | Model Training Do Not Wait For Inputs To Be Processed | Currently, when we train a context-based classifier model, we wait for all inputs to be added to your app before a model version is created and processed, with a 1 hour training timeout. In the future, we will use any available inputs and annotations that are available at the time a model version is created for training. If the input is pending or in progress, those inputs and associated annotations will not be used for training. You can use [https://api.clarifai.com/v2/inputs/status](https://api.clarifai.com/v2/inputs/status) to check input counts for each status. | | February 27, 2020. 9:00am ET | Deprecation of Face object from API | The Face object in our API responses will be deprecated in favor of a list of Concepts that other model types return. This should only affect users of the Celebrity, Demographics, or custom face recognition models as the `data.face` attributes like `data.face.identity`, `data.face.age_appearance`, `data.face.gender_appearance`, and `data.face.multicultural_appearance` will now be returned in the list of `data.concepts` Concept object. The API will return both for a while during the transition to give you time to update your code away from using the `data.face` objects altogether. We are doing this to simplify the API interface and make it more compatible for advanced functionality coming soon in workflows! The custom face recognition and celebrity models are a simple change to just access the new `data.concepts` field, but the demographics model is a more fundamental change away from having three distinct lists of concept to a single list. In order to cope with this, we have introduced a `vocab_id` field in each `data.concepts` entry returned by the demographics model so that you can distinguish `age_appearance`, `gender_appearance` and `multicultural_appearance`. To convert the new format to old format, check python example [here.](https://github.com/Clarifai/docs/tree/master/examples/deprecate_face_object) | | February 24, 2020. 9:00am ET | Consolidation of Input Related Status Codes | As we support more media types, it is impractical to have status codes for each. Thus status codes will now be prefixed `INPUT_...` rather than `INPUT_IMAGE_...` or `INPUT_VIDEO_...`. We will maintain the int value for the `INPUT_IMAGE_...` prefixed statuses, but no longer support the int values associated with statuses prefixed `INPUT_VIDEO...`. | | February 12, 2020. 9:00am ET | Deprecation of Face model type names | The `facedetect*` model types will be deprecated in favor of their more general `detect*` counterparts. For example these would be the changes of model type: `facedetect` -> `detect`, `facedetect-identity` -> `detect-concept`, `facedetect-demographics` -> `detect-concept`, `facedetect-embed` -> `detect-embed`. This change is to unify the APIs around face products and object detection products so that they are compatible everywhere either is used. | | February 3, 2020. 9:00am ET | `PATCH /inputs` overwrite action change | The overwrite action when patching inputs currently has some inconsistent behavior. If you patch `input.data.metadata` or `input.data.geo` fields on an input that has `input.data.concepts` already added to it, these concepts will remain after the patch even though the patch action was `overwrite`. Going forward, the overwrite behavior will overwrite the entire `data` object with what is included in the `PATCH /inputs` API call. Therefore if concepts are not provided in the patch call, but were originally on that input, they will be erased (overwritten with an empty list of concepts). You can maintain the current behavior by always sending back the complete `data` object from `GET /input/{input_id}` along with any modification to it if you are using the `overwrite` action. Update: this change has become more complicated than originally expected and we may not undergo it after all, more to come in the future. Still a good idea to update your PATCH calls to use the `merge` or `remove` actions instead of `overwrite` due to `overwrite`'s inconsistency. | | February 1, 2020. 9:00am ET | Deprecation of Focus Model | The Focus model will no longer be supported and will be removed from our API after this point in time. If you have requests for recognizing focus and blurry regions within images please contact [sales@clarifai.com](mailto:sales@clarifai.com) so that we can help you directly. | | November 20, 2019. 9:00am ET | `image.crop` argument will be deprecated | In some requests we used to allow cropping of images during the request using the `image.crop` field. This was for convenience only, but in reality it was rarely ever used and significantly complicates the processing pipelines under the hood. Therefore, we will no longer support the `image.crop` field in any requests that used to accept it. If you want to have similar behavior please crop the images on the client side and send the cropped bytes as base64 encoded image data. | | September 30, 2019. 5:00pm ET | `DELETE /inputs` will only operate asynchronously | Along the same lines as `POST /inputs` becoming completely asynchronous, we are cleaning up some inconsistent behavior in the API for deleting inputs. Previously, when a single image was deleted with `DELETE /inputs` or `DELETE /inputs/{input_id}` it was a synchronous operation, but when a batch of images were deleted it was asynchronous. We are making both asynchronous. This allows us to provide more advanced functionality with workflows that index your inputs. What this means for your code is if your application relies on the input having been deleted when the `DELETE /inputs` or `DELETE /inputs/{input_id}` calls return, you now need to add a second call to `GET /inputs/{input_id}` in order to check that it fails with a not found error. | | September 24, 2019. 5:00pm ET | `POST /inputs` will only operate asynchronously | We are cleaning up some inconsistent behavior in the API where a single image added with `POST /inputs` was a synchronous operation, but a batch of images was asynchronous. We are making both asynchronous. This allows us to provide more advanced functionality with workflows that index your inputs. What this means for your code is if your application relies on added inputs having already been indexed when the `POST /inputs` call returns, you now need to add a second call to `GET /inputs/{input_id}` in order to check the status of the input you just added to look for 30000 (INPUT_IMAGE_DOWNLOAD_SUCCESS) status code. | | September 11, 2019. 9:00am ET | Scheduled Database Downtime | We plan to upgrade our database to make it faster and provide more space for your applications. We expect a few minutes of downtime during this upgrade but you should plan for up to an hour of downtime in case things don't go as expected. This will primarily affect the following uses of our platform: POST/GET/PATCH/DELETE inputs, Search, Custom Training, Model Evaluation |