AI92 በቀጥታ ስርጭት ላይ ነው - ዓለም አቀፍ ለስላሳ ማስጀመሪያችን ተጀምሯል፡ ሙሉው መድረክ ለመጀመሪያዎቹ 30 ቀናት በዓለም ዙሪያ ክፍት ነው።
የሰነድ ምናሌ

እነዚህ የገንቢ ሰነዶች በአሁኑ ጊዜ በእንግሊዝኛ ብቻ ናቸው። ኮድ እና ኤፒአይ ባህሪ በሁሉም ክልሎች ተመሳሳይ ናቸው።

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.