Openfort API Versioning & Deprecation Policy
This page describes the compatibility guarantees of the Openfort REST API at https://api.openfort.io, so you can integrate against it — as a developer or as an automated agent — without worrying that the surface changes underneath you.
Versioning
The API is versioned in the URL path: all endpoints live under /v1/. Within a version, changes are additive only — new endpoints, new optional request parameters, and new response fields may appear, but existing endpoints, fields, and behavior are not removed or changed incompatibly. Your integration should tolerate unknown fields in responses.
Breaking changes only ship under a new version path (for example /v2/), with the previous version continuing to work in parallel during the migration period.
What counts as a breaking change
- Removing or renaming an endpoint, request field, or response field
- Changing a field's type or meaning
- Tightening validation so previously accepted requests are rejected
- Changing error codes for existing failure modes
Adding endpoints, optional parameters, response fields, or enum values is not considered breaking.
Deprecation and sunset
When an endpoint or field is deprecated, we announce it in the changelog and mark it in the API reference with a documented migration path. Deprecated surfaces keep working for a migration window of at least 90 days from the announcement before removal. Security fixes are the only exception to this timeline, and we contact affected projects directly when one requires action.
Machine-readable spec
The current API surface is published as an OpenAPI 3.0 document at openfort.io/docs/openapi.json. Agents should treat that spec as the source of truth for endpoints, parameters, and authentication schemes. See also the llms.txt agent guide and the developer resources index.