Change policy

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 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

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.

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.


Did this page help you?