Skip to content
ABTO Guide

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.

AreaSupported surface
MessagesText 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 lengthmax_completion_tokens and the legacy max_tokens alias
Number of responsesn omitted or set to 1
Streamingstream omitted or set to false
Structured outputresponse_format: { type: 'text' }, json_schema with an embedded schema, or json_object without tools
Tool callingtools 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 parameterstemperature, 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.

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: true or an n value other than 1
  • refusal on assistant messages. The tool_call_id of a tool message and the id of assistant tool_calls must be the values the response returned; anything else is rejected with unknown tool_call_id
  • Tools with type: 'custom', tool_choice of type custom, tool_choice sent without tools, functions sent together with tools, and parallel_tool_calls: false
  • Audio and content parts other than text, image_url, or file
  • Media parts in system, developer, or assistant messages
  • HTTP(S) image URLs, image_url.detail, file.file_id, unsupported MIME types, and malformed data URLs
  • json_schema without an embedded schema, and response_format: { type: 'json_object' } sent together with tools. json_object is supported only without tools
  • Fields outside the allowlist such as stop, logprobs, modalities, metadata, or service_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.

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.