Browse documentation
Docs
API Changelog
v1 is stable. Changes are additive-only. Breaking changes require a new major version (v2).
Versioning policy
v1 is stable
The /api/v1 base URL will not break existing integrations. No endpoints will be removed or have their request/response shapes changed in a backwards-incompatible way within v1.
Additive-only changes
New endpoints, new optional request fields, new response fields, and new enum values may be added to v1 at any time. Clients must ignore unknown fields to stay forward-compatible.
Deprecation windows
When a behaviour needs to change (rare), it will be marked deprecated in the changelog with a minimum 90-day removal window. Deprecated fields/endpoints continue to work during that window and emit a Deprecation response header.
Breaking changes require v2
Removing endpoints, changing required fields, or altering response shapes in backwards-incompatible ways requires a new major version (/api/v2). Both versions are supported in parallel for at least 12 months after v2 launches.
| Change type | Can happen in v1 | Requires new version |
|---|---|---|
| Add new endpoint | yes | no |
| Add optional request field | yes | no |
| Add new response field | yes | no |
| Add new enum value | yes | no |
| Add new ability scope | yes | no |
| Change error message text | yes | no |
| Remove endpoint | no (90-day deprecation window) | yes |
| Remove required request field | no | yes |
| Change response field type | no | yes |
| Remove response field | no | yes |
| Change URL structure | no | yes |
Change history
This history is updated whenever the API changes, so you can see what changed and whether any action is required.
Full API v1 released. Covers Auth, Signals, Measure, Plan, Intel, Build, Triage, Knowledge, Outcomes, Usage, Work Orders, and Runners pillars.
Was this article helpful?
Your response enters the same customer insight queue used by product feedback.