Versioning

The public API is versioned in the URL — every endpoint lives under /v1. Ordinary schema evolution is additive. Security authorization fixes can tighten access within /v1; the November 2026 scope upgrade intentionally requires new read grants and rejects unpartitioned Test reads.

What’s a breaking change

The ordinary schema-versioning policy treats these as breaking:

• Removing an endpoint, field, or event type.
• Renaming a field, or changing its type.
• Adding a new required request parameter.
• Changing the meaning of an existing value.

What can change without notice

These are additive and can ship at any time, so build to tolerate them:

• New endpoints.
• New optional request parameters.
• New fields on existing responses.
• New event types, and new status/enum values on existing objects.

Staying informed

Additive changes and any future version work are recorded in the changelog. Material changes to existing behaviour are announced ahead of time to registered developers. A whole new major version (a hypothetical /v2) would run alongside /v1 — your existing integration keeps working until you choose to migrate.