Embrasure API versioning and deprecation.

Product endpoints use a versioned URL. Deprecated operations stay discoverable long enough for clients to migrate, with dates in both the API contract and HTTP response headers.

Versioning

Stable product endpoints live under /v1. Embrasure may add endpoints, optional request fields, response fields, enum values, and error codes within the current version. A change that removes a supported operation or changes the meaning of an existing field requires a new versioned path or a documented migration.

The canonical contract is the Embrasure OpenAPI specification. Every operation has a unique operation identifier, typed inputs and outputs, and a description.

Deprecation timeline

A generally available operation receives at least 90 days between a public deprecation notice and its sunset date. Preview, beta, unused compatibility files, and changes required for security or legal reasons may use a shorter window. The migration note will say when an exception applies.

OpenAPI	The operation is marked deprecated and points to its replacement.
Deprecation	The response carries the announcement date as an RFC 9745 structured date.
Sunset	The response carries the final support date as an RFC 8594 HTTP date.
Link	The response links to migration guidance with rel="deprecation".

Deprecation: @1787443200
Sunset: Sat, 21 Nov 2026 00:00:00 GMT
Link: <https://embrasure.ai/docs/api/versioning>; rel="deprecation"; type="text/html"

Rate limits and retries

Embrasure does not impose a global API request quota today. An operation with a concrete quota publishes its policy with RateLimit-Policy and its current availability with RateLimit. These structured fields follow the current IETF HTTPAPI rate-limit specification. A 429 response also includes Retry-After, which takes precedence over other timing hints.