Skip to main content
The Chataigne API includes its major version in the URL path:
There is no unversioned alias or version header. Always include /v1 in the URL your integration calls.

​
Additive changes

Compatible additions can be released within v1. They include:
  • New endpoints or optional request parameters.
  • New optional fields in response objects.
  • New resource or error-code variants.
  • New response headers.
  • Relaxed validation or a previously required field becoming optional.
Write forward-compatible clients: read the fields you need, ignore fields you do not recognize, and avoid assuming that a JSON object has a fixed set of keys.

​
Breaking changes

Changes that could make a correct client stop working require a new major version. Examples include:
  • Removing or renaming an endpoint or field.
  • Changing an existing field’s type or meaning.
  • Adding a required request field.
  • Changing pagination, authentication, or error-status behavior.
  • Removing a documented enum value.
When a new major version is introduced, its changes and migration steps will be published in the Changelog. Existing versions will run in parallel for a communicated migration period.

​
Client recommendations

  • Keep the version segment in one configurable base URL.
  • Validate the fields your integration requires, but tolerate additional fields.
  • Treat resource IDs and cursors as opaque strings.
  • Monitor the changelog and test a new major version before switching production traffic.
Node.js