Our primary goal is to provide a stable API that you can rely on for your integrations. We currently operate on an unversioned API, and we are committed to making backward-compatible changes.

Should we need to introduce backward-incompatible (breaking) changes, we will release a new, distinct API version (e.g., v2). The previous version will be maintained and supported for a reasonable deprecation period to allow clients to migrate. We will provide clear timelines and guidance for any such transitions.

​
Backward-compatible changes

We regularly release backward-compatible enhancements and features. Your integration should continue to work seamlessly when these changes are deployed, though you may want to update your code to take advantage of new capabilities.

Non-breaking changes include:

  • Adding new API endpoints
  • Adding new optional parameters or fields to existing API request bodies or query strings
  • Adding new fields to API responses or webhook payloads
  • Adding new webhook event types
  • Adding new values to existing enums

This is particularly important for fields like validation alert codes or error codes. As our product evolves, new codes will be added.

Client applications should be designed to gracefully handle unrecognized enum values in a non-blocking manner, rather than failing the process.