Migration and compatibility
Migration and compatibility for Q integrations.
New integrations should use the deployed /v1 contract and the quickstart. A prefix change alone does not establish equivalent scopes, errors, replay or durable execution. Compare your exact operation in capabilities and the API reference.
- Provision least-privilege backend credentials for the intended tenant/principal.
- Select a supported SDK and matching API version using the support matrix.
- Preserve request/operation keys, durable run receipts and event cursors across retries. Follow idempotency, run lifecycle and event journal.
- Use machine answer streaming when consuming final results programmatically. Draft tokens are not a verified final answer.
- Inspect deprecation/sunset headers and the maintenance policy. Removal requires separate conformance, usage and rollout review.
Existing legacy paths are compatibility surfaces, not a fallback to try automatically after a failed mutation. Q7.4 consolidates internal stream response formatting without removing either wire format. Historical examples remain in the earlier migration guide; use current reference schemas rather than copying an old hostname or payload unchanged.
Q2.2 schema and error contracts
Use the current schema and error contract for strict request models, named response envelopes, admission limits and retry guidance. Keep operation IDs and response media types stable; protocol-specific errors and status documents retain their declared shapes.