Integration guide
Gateway OpenAI compatibility
Supported and rejected OpenAI Chat Completions fields for the Node.js and Python SDKs.
The ABTO Gateway has one data path, POST /v1/chat/completions,
and accepts requests in the OpenAI Chat Completions format.
This does not mean that every OpenAI SDK API and field is supported.
The SDKs that use this path are Node / Server JavaScript and Python.
Supported requests
Section titled “Supported requests”| Area | Supported surface |
|---|---|
| Messages | Text content for system, developer, and assistant. A user message may be a text string or an ordered array of text, inline image_url, and inline PDF file parts. |
| Output length | max_completion_tokens and the legacy max_tokens alias |
| Number of responses | n omitted or set to 1 |
| Streaming | stream omitted or set to false |
| Structured output | response_format: { type: 'text' }, json_schema with an embedded schema, or json_object without tools |
| Tool calling | tools entries with type: 'function' (name, description, parameters, strict), tool_choice as none, auto, required, or { type: 'function', function: { name } }, { type: 'allowed_tools', allowed_tools: { mode, tools } }, and parallel_tool_calls omitted or true. Legacy functions, function_call, and the role: 'function' message are accepted too, and such requests get message.function_call with finish_reason: 'function_call' back. Otherwise the response carries message.tool_calls with finish_reason: 'tool_calls', and each id is issued by the Gateway. For the next turn, append that assistant message and a role: 'tool' result per call, echoing the response id as tool_call_id. Gemini has no per-tool strict, so if any tool sets strict: true, every tool in that request is schema-validated (validation only ever becomes stricter, never looser). |
| Quality parameters | temperature, top_p, frequency_penalty, presence_penalty, seed, reasoning_effort, verbosity |
The Node.js and Python SDKs carry the original request body to the Gateway. When a feature policy applies, its variant may replace the model, system instructions, and quality parameters. Requests without a policy use their original values.
Media content parts are supported in user messages only.
An image must use image_url.url with data:image/png;base64,..., data:image/jpeg;base64,...,
data:image/webp;base64,..., or data:image/gif;base64,....
A PDF must use file.file_data with data:application/pdf;base64,... and may include file.filename.
Unsupported requests
Section titled “Unsupported requests”Paths other than POST /v1/chat/completions, including the Responses API, return 404.
Using another HTTP method on the supported path returns 405.
With the correct path and method, the following requests fail with 400 instead of being silently ignored:
stream: trueor annvalue other than1refusalon assistant messages. Thetool_call_idof atoolmessage and theidof assistanttool_callsmust be the values the response returned; anything else is rejected withunknown tool_call_id- Tools with
type: 'custom',tool_choiceof typecustom,tool_choicesent withouttools,functionssent together withtools, andparallel_tool_calls: false - Audio and content parts other than
text,image_url, orfile - Media parts in
system,developer, orassistantmessages - HTTP(S) image URLs,
image_url.detail,file.file_id, unsupported MIME types, and malformed data URLs json_schemawithout an embedded schema, andresponse_format: { type: 'json_object' }sent together withtools.json_objectis supported only without tools- Fields outside the allowlist such as
stop,logprobs,modalities,metadata, orservice_tier - Unknown fields, including typos and newly introduced provider fields
Unsupported input is never removed or rewritten into a different meaning, so only requests the Gateway actually accepted enter experiments and operational records.
Inspecting errors
Section titled “Inspecting errors”Every POST /v1/chat/completions response carries x-abto-request-id, including failures and admission rejections.
Read the raw response header in the SDK and use it to connect to request details.
Provider, transport, and internal failures may also include x-abto-error-source.
Routing-level 404 and 405 responses do not include x-abto-request-id.
Calls handled by OpenAI direct fallback never pass through the Gateway,
so they have no ABTO telemetry, variant policy, or x-abto-request-id.