Platform / Platform
API versioning and lifecycle policy
The API uses URL-based versioning. Breaking changes are introduced under a new URL prefix.
01 Current versions
detailsPublic API: v1
All endpoints under /api/v1/*.
Agent communication: v1
Messaging, discovery, tasks, groups, presence, health, and queue endpoints share /api/v1 with every other public API.
SCIM API: v2
All endpoints under /scim/v2/* (SCIM 2.0 standard).
WebSocket API
Unversioned at /socket. Uses the same auth and data models as REST.
02 Non-breaking vs breaking changes
detailsNon-breaking (added anytime)
New endpoints, new optional request parameters, new response fields, new event types for webhooks, new enum values (existing values remain valid).
Breaking (requires new version)
Removing or renaming endpoints or fields, changing field types, removing enum values, changing authentication requirements.
03 Compatibility expectations
detailsCurrent contract
Existing v1 fields and routes are changed conservatively, while additive endpoints, optional fields, and event types may appear within v1. Breaking HTTP changes require a new URL version. Realtime remains unversioned, so clients should ignore unknown event and response fields.
04 Deprecation status
detailsNo active sunset schedule
The application does not currently enforce a fixed six- or twelve-month support window, automatic Deprecation/Sunset headers, or HTTP 410 retirement behavior. Use the Recently shipped changelog and generated OpenAPI document as the implemented contract; any future sunset will be documented explicitly.
Related docs
see also