Change policy
Learn how we communicate key product changes to you
We always try to make changes to our product in a backwards-compatible way. This means you can choose whether, when and how to update your code and take advantage of the new functionality.
Backwards-compatible changes
The following changes are normally considered as backwards-compatible.
- Any additive changes to the Codat API or front end products, such as:
- a new datatype or API endpoint
- a new field within a datatype or API endpoint
- a new integration
- a new portal page
- a new rule
- a new optional parameter to an API endpoint
- Front end changes that do not materially alter the functionality available or the way that functionality is accessed
See our Product Roadmap to see the new functionality we're planning, working on, or have recently released.
Breaking changes
Breaking changes are changes that are not possible to make backwards-compatible. When deprecating these, we try to follow the parallel change pattern (also called the expand and contract pattern).
When planning to make a breaking change, we'll post the details of the upcoming deprecation on our Important updates at least three months before it is released.
We'll also send an email to all developer and administrator users in the first week of each calendar quarter (January, April, July, October) with a summary of the upcoming deprecations.
These users can also choose to enable the deprecations early in the Codat Portal.
Opt-in to changes early
If you'd like to opt-in to a breaking change before its planned implementation date, you can do so in the Developers section of the Codat Portal by navigating to Developers > API deprecations.
Ensure you are familiar with the details of the deprecation you plan to enable and have completed any necessary preparations.
Only users with developer and administrator roles are able to access the Developers tab and enable the deprecations early.
Deprecation schedule
You can also subscribe to our deprecation calendar.