Compatible transport and response shape
The gateway uses bearer authentication, a /v1/chat/completions path, familiar role/content messages, and choices/usage response fields. A client that lets you configure its base URL and key can use those supported fields.
This is a constrained compatibility surface, not a full implementation of every OpenAI API feature. Set the base URL to the Gateway, use a Gateway key, and choose a Gateway alias.
Migration checklist
- Replace the provider key with an environment-specific Gateway key.
- Replace the provider endpoint with the Gateway base URL.
- List allowed models; do not assume upstream model names are callable.
- Check the selected route’s capabilities and remove unsupported fields.
- Disable unconditional SDK retries; apply outcome-aware retry handling.
- Check usage metadata and verify the synthetic-data path before any approved healthcare rollout.
Explicitly unsupported
- Images, audio, embeddings, files, batch, hosted tools, remote MCP, and the Responses API are not exposed.
- Tools on GPT-6 Astra and GPT-6.1 Sol are unavailable through our current Chat Completions endpoint.
- Arbitrary metadata, provider credentials, fallback configuration, and caller-controlled storage remain rejected.
- Unknown schemas and unsupported capabilities fail before provider dispatch.
SDK version differences
The official OpenAI SDKs work with the supported fields: set the base URL to https://gateway.accountablehq.com/v1, use a Gateway key, and set maxRetries: 0 (JavaScript) or max_retries=0 (Python). Pass an Idempotency-Key header per logical request and retry only with the same key. Pin the SDK version and test its outgoing requests against the current OpenAPI schema, since newer SDK versions can add fields the gateway rejects.