API Compatibility
See which OpenGateway endpoints each model supports, how common request and reasoning fields are normalized, and where Gemini-specific fields are accepted.
OpenGateway exposes OpenAI-compatible request formats for chat, responses, embeddings, and images, plus the Anthropic Messages format and the Decisions API. Provider mapping happens behind the API surface, but support is model- and endpoint-specific.
Find supported endpoints#
GET /v1/models is public and returns each model’s endpoints array. Use the exact model ID from the catalog and call an endpoint only when its corresponding value appears in that model’s array. A key restricted to an allowlist sees only the models it can use.
| API | Route | Catalog endpoints value |
|---|---|---|
| Chat Completions | POST /v1/chat/completions | chat_completions |
| Responses | POST /v1/responses | responses |
| Anthropic Messages | POST /v1/messages | messages |
| Embeddings | POST /v1/embeddings | embeddings |
| Image generation | POST /v1/images/generations | images_generations |
| Image edits | POST /v1/images/edits | images_edits |
| Decisions | POST /v1/decisions | decisions |
GET /v1/models is the catalog route; it is not a per-model endpoint value. Endpoint support is not inferred from a provider name: check the model’s own endpoints array. See models and routing and the current model catalog.
OpenAI-compatible normalization#
For Chat Completions and Responses, send the endpoint’s OpenAI-style request shape. OpenGateway maps supported fields to the selected provider’s request format; values or fields that cannot be used by a provider may be adapted or omitted according to that model’s mapping rules.
Chat Completions supports the OpenGateway extension extra.normalize, which defaults to true. Set it to false to request minimal correction; the gateway still performs the format conversion needed to call the provider. To inspect transformations, request extra.debug: ["normalizations"] and read the debug.normalizations response data. Debug output is an explanation of changes, not a switch that changes provider support.
Reasoning fields#
Use the standard reasoning field for the API you call:
| API | Field | Notes |
|---|---|---|
| Chat Completions | reasoning_effort | Common effort labels are minimal, low, medium, high, xhigh, and max; none requests disabled reasoning where supported. Accepted levels and their effect depend on the model. |
| Responses | reasoning.effort | Uses the Responses request shape. Support and accepted values depend on the model. |
The gateway maps these standard fields to provider controls where its adapter supports them. For Gemini Responses, reasoning.effort maps to Gemini thinking configuration. Do not send it together with native_fields.thinking_config in the same request.
Provider-specific fields#
Provider-specific fields are typed extensions, not an arbitrary raw-body tunnel. In particular, native_fields has a defined schema and is consumed only by supported provider adapters; unknown keys are rejected rather than passed through.
For Gemini Responses models, the current adapter supports these fields:
| Field | Purpose |
|---|---|
native_fields.thinking_config | Gemini thinking_budget, thinking_level, or include_thoughts. Use this instead of reasoning.effort, not alongside it. |
native_fields.safety_settings | A list of Gemini safety category and threshold values. |
native_fields.top_k | Gemini top_k sampling setting. |
native_fields.labels | Gemini request labels as a string-to-string map. |
For Gemini Chat Completions, use the supported top-level thinking_config and safety_settings fields instead. The Chat Completions Gemini adapter rejects non-empty native_fields; do not copy the Responses shape to that endpoint. Other providers may reject native fields they do not implement. For example, the OpenAI Responses adapter rejects non-empty native_fields.
Use an endpoint and fields that the selected model supports. For Anthropic’s request and response format, see the Messages reference; for tool schemas, see tool calling.