Versioning & deprecation

The contract is /open/v1. We add fields and endpoints without notice; we never remove or repurpose them inside a major version.

What counts as non-breaking

• Adding a new endpoint, a new optional request field, or a new response field.
• Adding a new value to an enum you only read (design your parsers to tolerate unknown values).
• Adding a new webhook event type (your subscription controls what you receive).

What we will never do without a deprecation cycle

• Remove or rename a field or endpoint.
• Change a field's type, or tighten validation on an existing field.
• Change the meaning of an existing enum value or error code.

How deprecations are announced

A deprecated operation returns RFC 8594 Deprecation and Sunset headers, appears in the console banner, and is published in the changelog. The default window is 12 months between deprecation and sunset unless a shorter one is stated for a security reason.