Versions
Open in the interactive reference
Every request names the version it is written against in the Api-Version header. A request without the header, or with a version that does not exist, is refused with 400. Because the version is always explicit, an integration on a stable version keeps the contract it was built against.
An endpoint that is not part of the requested version answers 404, exactly like a path that does not exist.
Choosing a version
| Version | Status |
|---|---|
v1 |
Stable |
Every version of the API is either stable or in preview.
A stable version doesn't change in ways that break an integration built against it. It can still grow: new endpoints, new optional fields, new fields in responses and new values in fields documented as strings can be added. Build your integration to ignore fields it doesn't recognize, and to handle a value it hasn't seen before.
A preview version is still being built. Its endpoints, fields and behavior can change in ways that break an integration, without notice. Use a preview version to try what is coming, and build production integrations against a stable version.
Version numbers
Versions are numbered v1, v2 and so on, and the number is what you send in the Api-Version header. A new number is created only for changes that would break an integration, such as removing or renaming a field, making an optional field required, or narrowing what a field accepts. Everything else is added to the existing version.
A new version starts as a preview and becomes stable later. It keeps its number when it does, so an integration built against it doesn't need to change its header.
Changelog
R71 - Monday, September 21, 2026
- v1 (stable): First release of the API.
Examples
Pinning a version
Api-Version: v1