ahlan hamad

Versioning and deprecation

How versions work

Before and after a release ships

We publish the contract ahead of the implementation so you can build in parallel. Before a release ships its shapes may still change, and every such change goes in the changelog. After it ships, v1 changes additively only.

Changes we make within v1 without notice

Build to tolerate them: ignore fields you don't recognise, handle unknown enum values gracefully, don't depend on field order, branch on an error's code rather than its title, and treat an unknown error code by its HTTP status.

Breaking changes go to v2

We never make any of these within v1:

If we need any of them, we ship /v2 alongside /v1, and v1 keeps working for at least [notice period to be confirmed] from the day its deprecation is announced.

How we announce a deprecation

  1. A Deprecated entry in the changelog with the shutdown date.
  2. The operation or field marked deprecated: true in openapi.yaml, so it shows in the reference and the Postman collection.
  3. Email to the registered developer contacts and to companies using what is going away.
  4. Deprecation and Sunset headers on the affected operations' responses until the shutdown date.

Previews

Features marked preview — currently OAuth — are outside this policy until they are generally available, and may change without a notice period.