Versioning

The version lives in the path

Every endpoint carries the version in its path, for example /api/v1.0/sales. There is no header or query-parameter version negotiation: the path is the contract, and the reference sidebar shows which versions each API exposes.

Backward-compatible changes

These can ship at any time and your integration must tolerate them:

• A new field in a response.
• A new optional parameter.
• A new value in an enumeration.
• A new endpoint.
• Different wording in an error message, with the same error identifier.

Two rules for your client follow:

1. Ignore unknown fields. A strict parser turns our improvement into your outage.
2. Have a default branch for enumerations. A new value should not raise.

Breaking changes

These never ship without prior notice:

• Removing or renaming a response field.
• Changing a field's type.
• Making an optional parameter required.
• Changing the meaning of an existing field.
• Removing an endpoint.

This portal's reference is generated from the published OpenAPI document, so what you read here is the API's real state rather than a copy someone remembered to update.

Documentation URL stability

Reference page addresses are a contract too. A documented endpoint keeps its address even if the API path changes: a redirect is added and old links keep working. Link them from your runbooks safely.