Billing support
API Versioning and Deprecation
Define API stability, breaking changes, model aliases, retirement notices, and migration rules.
/v1 is meaningful only with an explicit compatibility commitment. Manage API fields, model versions, and prices separately, leaving developers an actionable migration window.
Policy parameters require confirmation. Notice periods, support windows, and SLA values need formal APIQIK product and operations approval. This page does not prescribe a number of days.
Change categories
| Type | Examples | Release requirements |
|---|---|---|
| Compatible addition | Optional fields, models, or endpoints. | Update references, examples, and changelog; clients should tolerate unknown fields. |
| Behavior change | Defaults, routing, limits, or model-alias targets. | Explain impact, effective time, validation, and rollback. |
| Breaking change | Removed fields, changed types, retired endpoints. | Advance notice, migration guidance, and a parallel-support window. |
| Emergency security change | Vulnerability fixes or removal of high-risk capabilities. | Act promptly and explain impact and alternatives where safe. |
Model lifecycle
- Label models Preview, Stable, Deprecated, or Retired.
- Define whether aliases upgrade automatically; use fixed versions where reproducibility matters.
- Retirement notices should include replacement models, capability and price differences, migration examples, and deadlines.
- Update the status page and changelog if a provider urgently withdraws a model.
Notification channels
Major changes should appear in the documentation changelog, console notices, and account-contact communications. Enterprise users may receive machine-readable updates through subscriptions or webhooks where available. Always use explicit time zones.