API versioning and deprecation#

The supported REST API is versioned in its URL. New integrations should use https://api.multilocale.com/api/v1/. The unversioned /api/ prefix remains a compatibility alias, but clients should not depend on that alias when building a new integration.

Compatible changes#

Multilocale can add optional request fields, response fields, resources, and operations within v1. Clients should ignore response properties they do not recognize and should rely on the published OpenAPI document instead of assuming that an object has a fixed set of fields.

An incompatible request or response change requires a new major path such as /api/v2/. Existing versioned paths do not silently adopt the incompatible contract.

Deprecation policy#

No v1 endpoint is currently deprecated or scheduled for removal. If an endpoint or major API version is deprecated, Multilocale will:

1. Mark it as deprecated in the OpenAPI specification and developer guides.
2. Publish its replacement and migration instructions.
3. Include a Deprecation response header while the endpoint is deprecated.
4. Include a Sunset response header once a removal date has been scheduled.
5. Keep the endpoint available until the published sunset date.

Agents should treat the Deprecation and Sunset headers on a live response as the authoritative status and timing. A missing Sunset header means no removal date has been announced; it does not mean an endpoint can be assumed permanent.

Discover the current contract#

• OpenAPI specification
• REST API reference
• Authentication guide

Pin generated clients to a reviewed OpenAPI revision, and regenerate them after intentional contract updates.