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.
The following changes will normally be 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 are changes that are not possible to make backwards-compatible. When deprecating these, we try to follow the parallel change pattern (also called 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.
These users can also choose to enable the deprecations early in the Codat Portal.
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.
Updated 23 days ago