Versioning and stability
The version is in the path
https://api.flowbeacon.ai/api/public/v1/...
- Additive changes (new optional fields, new endpoints, new optional headers) ship in place on
v1and are not considered breaking. - Breaking changes require a new path prefix (
/v2) and a minimum 180-day parallel-operation window. - The platform's internal version (
info.versionin the OpenAPI document) tracks documentation updates; the path prefix is the stability promise.
Deprecation policy
When a field or endpoint is scheduled for removal:
- A
Deprecationresponse header is added, carrying the removal date in RFC 3339 format. - A
Sunsetresponse header is added per RFC 8594. - The Changelog is updated with the migration path.
- Existing integrations have at least 180 days from the first deprecation notice before removal.
Monitor these headers in your client and surface the deprecation date to engineers.
What's considered stable
| Surface | Stability |
|---|---|
Response envelope shape ({ ok, data, meta }) | Stable. Cannot change without a major version bump. |
Envelope.meta.watermark | Opaque token. Format can change. |
Error envelope shape ({ ok: false, error, detail }) | Stable. |
Documented error codes | Stable. New codes may be introduced; existing codes remain. |
| Documented endpoints and their request/response schemas in the OpenAPI document | Stable additive evolution. |
Policy shape — five fields exactly | Stable. Clients should ignore additional fields. |
Per-violation severity value | Contextual — prefer catalog severity. |
ScenarioResults.evaluation_status | Stable since this revision. |
What's intentionally undocumented
- The exact algorithm used to choose which policies apply to a scenario.
- The internal evaluator output that produces violations.
- Watermark generation seed.
- Any field not listed in the OpenAPI document.
If you rely on something not in this site or the OpenAPI document, please raise it on partners@flowbeacon.ai so we can stabilise it formally.
Versioning infrastructure in these docs
This documentation site has versioning infrastructure ready but does not yet cut snapshots. When v2 ships, we will run:
npm run docusaurus -- docs:version 1.1
to snapshot the current docs as 1.1, then continue iterating on v2 in current. Until then, the docs always reflect the latest v1 surface.
Next steps
- Changelog — every documented change.
- Error taxonomy — stable error codes.