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.

Non-backwards-compatible changes

If it isn't possible to make a change backwards-compatible, we try to follow the parallel change pattern (also called expand and contract pattern).

When we're planning to make a non-backwards-compatible change, we'll post the details on our changelog at least three months before the change 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 changes.

Opt-in to changes early

If you'd like to opt-in to a change before its planned implementation date, please email our support team.

Did this page help you?