The Annature API uses path-based versioning to ensure backwards compatibility as new features and improvements are introduced. All endpoints begin with the v1 prefix. When future versions of the API are released, you’ll be able to target them explicitly by changing the version in the request URL. If a specific resource supports multiple versions, this will be documented in its reference section. Versioning allows you to confidently build against a stable contract while still benefiting from improvements that don’t break your existing integration.

​
Backwards-compatible changes

We may introduce backwards-compatible changes to the v1 API without prior notice. Your integration should be designed to handle these changes safely. Examples of backwards-compatible changes include:
  • Adding new optional parameters to a request
  • Adding new properties to a response payload
  • Adding new Webhook event types
These changes will not break existing functionality and are intended to be additive.

​
Breaking changes

Changes that alter the expected structure or behavior of the API are considered breaking. When such changes are necessary, they will result in a new versioned endpoint (e.g. v2). Examples of breaking changes include:
  • Removing or changing the behavior of a request parameter
  • Removing or changing the type of a response property
  • Introducing new validation rules that block previously accepted input
  • Changing the HTTP status code returned by an endpoint