Deprecation is fair warning that a part of the Codat platform will soon be changed. This includes, but is not limited to, changes to endpoints, data types, the Codat data model, and core infrastructure.
Wherever possible, we make changes backward-compatible. We consider the following changes to be backwards compatible, and so not breaking changes:
- Adding new API endpoints.
- Adding new optional parameters to existing endpoints.
- Adding new data elements to existing response schemas.
- Adding new error types and error codes.
- Adding new webhook types.
- Changing the length of content of any API identifier
If a change is not backward-compatible, then it is your responsibility to upgrade your code within the deprecation notice period.
Deprecation notice period
Changes are announced, and made, on the second Wednesday of each month. Between the date of announcement and deprecation there are 12 weeks for you to upgrade your code.
Any additive changes to the Codat API are excluded from the policy. For example:
- Adding a new field to a data type.
- Adding a new data type.
- Adding a new integration.
As part of deprecation, Codat sends a monthly email communication to all clients to encourage them to upgrade their code to prevent any breaking changes.
Changes are announced, and made, on the second Wednesday of each month. On the day a new change is announced, alternative functionality is immediately available in Codat's UAT and Production environments.
Between the date of announcement and deprecation there are 12 weeks for all planned changes. For example, if a depreciation change is announced on Wednesday 8th April 2020, the new functionality is made available on the same day, but the old functionality doesn't go out of support until Wednesday 1st July 2020.
Throughout the notice period, Codat’s Support team is available to help with questions about the changes.
On the second Wednesday of each month, Codat sends an email update to all Codat clients that are Administrator or Developer users. The email explains any planned changes, as well as any deprecation that has taken place, and includes:
- What is being changed and why.
- When the change will happen.
- What will happen when the functionality is changed.
- Any alternative functionality that has been made available. This functionality will be available from the day of the announcement so that code updates can take place during the notice period, to prevent any breaking changes, and to allow a smooth changeover.
- What functionality, if any, has been removed on the day the email is sent.
Updated 7 months ago