Versioning

The AI92 API is versioned in the URL path. The current and only stable version is /v1:

https://api.ai92.ai/v1/...

Every endpoint in these guides lives under /v1. We commit to keeping /v1 stable and backward-compatible.

What "backward-compatible" means

Within /v1, we may make additive changes at any time, without notice, and your integration must tolerate them. Specifically, we may:

• Add new endpoints and new services.
• Add new optional request parameters (existing requests keep working unchanged).
• Add new fields to response bodies and to the data object of webhook events.
• Add new event types, error codes, job-id prefixes, and response headers.
• Add new enum values to existing fields.

To stay compatible, build a tolerant reader:

• Ignore unknown JSON fields — don't fail when a response gains a property.
• Handle unknown enum values gracefully (e.g. a future job status or event type).
• Branch on error.code and on HTTP status families, not on exact message strings.
• Don't depend on field ordering or on the absence of a field.

What counts as a breaking change

These are never made silently within /v1:

• Removing or renaming an endpoint, field, error code, or event type.
• Changing the type or meaning of an existing field.
• Adding a new required request parameter.
• Tightening validation in a way that rejects previously valid requests.
• Changing default behavior in a way that alters existing responses.

A breaking change ships as a new major version (e.g. a future /v2). /v1 and the new version run side by side during the transition — your /v1 integration keeps working.

Deprecation policy

When we plan to retire something, you get advance, explicit notice:

1. Announcement in the changelog and via email to account owners.
2. A deprecation window during which the old behavior continues to work. We target a minimum of 12 months for retiring a major version after its successor is generally available.
3. Deprecation and Sunset response headers on affected endpoints during the window, with a link to migration docs.
4. A migration guide describing exactly what changes and how to move.

Nothing is removed before its announced sunset date.

Recommendations

• Pin to /v1 explicitly in your base URL — never call the host without a version segment.
• Subscribe to the changelog so you hear about additive changes and any future deprecations early.
• Test against the sandbox when adopting new fields or endpoints before relying on them in production.