Skip to main content
The public API is versioned in the URL — every endpoint lives under /v1. We add to v1 over time, but we won’t break what’s already there.

​
What’s a breaking change

We treat these as breaking, and they will not happen within /v1:
  • 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.
Don’t treat unknown fields or event types as errors. Ignore response fields you don’t recognise, and handle unknown event type values gracefully — this is what keeps your integration working as the API grows. See event types.

​
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.