Request Parameter Handling

A request to AISIX often carries parameters the selected upstream handles differently from the API the client was written for: a penalty a model does not take, a stop that one family refuses, or an OpenAI field that Anthropic has no name for. This page explains what AISIX does with each request parameter, so you can tell in advance whether a parameter reaches the model, disappears, or fails the request.

How AISIX Decides

AISIX handles each field the caller sends by what the target platform's own API defines for it. The same rules apply to a request in the upstream's own protocol and to one AISIX translates:

1. The target defines the field and the value fits it. AISIX writes the value as the caller sent it, or moves it into the field with the same meaning when the target names or places it differently, such as OpenAI's stop becoming Gemini's stopSequences. AISIX does not drop the value, rewrite it, or check it on the upstream's behalf. If the model refuses it, the upstream's status and message reach the caller.
2. The target has no place for the field or the value. AISIX drops it silently, without a log line, header, or metric.
3. The value is not valid in the caller's own protocol, and the target cannot receive it as written. AISIX refuses the request with 400 invalid_request_error, and the message names the field.
4. Whatever the upstream answers comes back in full. See The Whole Answer Comes Back.

AISIX can use what it knows about a model or family to decide where a value goes: which field, which upstream route, or which name. It does not use that knowledge to decide whether a value is dropped, refused, or changed. A parameter you send to a model that does not support it therefore reaches the model, and you receive the provider's own error.

Without Protocol Translation

When the caller's protocol is the upstream's protocol, such as /v1/chat/completions to an OpenAI-compatible provider or /v1/messages to Anthropic, the target defines every field the client can send. AISIX forwards the body as sent, including fields AISIX does not know itself, and the upstream judges each one. The changes AISIX still makes are the ones a provider page documents, such as the reasoning-model token cap on OpenAI, and the ones the operator configures on the provider key, such as request.param_renames.

With Protocol Translation

When AISIX translates the request, such as an OpenAI-style request to Claude or Gemini, or a /v1/messages request to an OpenAI-compatible model, each field is mapped to the target's field with the same meaning. A field the target protocol has no equivalent for is dropped. A value that the caller's protocol does not allow, such as a stop that is a number, is refused with a 400 naming the field, because the translated request has nowhere to carry it for the upstream to judge.

The provider pages list the mappings for each translation:

• OpenAI Client with Anthropic Upstream
• Request Fields on the Translated Path for /v1/messages to a non-Anthropic upstream
• Amazon Bedrock
• Gemini on Vertex AI

Deliberate Exceptions

Four behaviors depart from these rules on purpose:

• The Anthropic attribution line, which Claude clients add to system, is removed for every upstream other than Anthropic's own API. See Anthropic Attribution Line.
• An ensemble model's judge call uses sampling parameters the gateway sets, not the caller's.
• A single empty-string stop is not sent to Amazon Bedrock Converse, which rejects it.
• The Responses bridge carries the Responses API fields that coding agents such as Codex send. Other Responses API fields are outside its scope.

What the Caller Receives

Situation	Result
The target takes the parameter.	The parameter reaches the model.
The target defines the parameter, but the model refuses it or its value.	The upstream's status and message, such as a 400 from Amazon Bedrock with This model doesn't support the stopSequences field. Remove stopSequences and try again.
The target has no place for the parameter.	The request succeeds without it.
The value is not valid in the caller's protocol, on a translated path.	400 invalid_request_error, with the field named in the message.
The body is valid JSON but does not fit the endpoint's request format.	400 invalid_request_error whose message starts with invalid request body: and names the field path, such as max_tokens or messages[0]. A message content that is a number, boolean, or object is refused the same way.

A consequence to plan for: a request that used to succeed while the gateway silently ignored a parameter can now receive the upstream's 400. Stop sending that parameter to that model, or choose a model that takes it. A gateway at 1.7.0 or earlier dropped several such parameters itself; the cases that changed are listed in Requests That Now Fail.

The Whole Answer Comes Back

On /v1/chat/completions, AISIX returns everything the upstream answered:

• Every choice, so a request with n greater than 1 receives every choice. Streamed chunks keep each choice's index.
• Each choice's logprobs.
• refusal, annotations, the legacy function_call, and every other message or delta field the upstream sent.
• A message content that the upstream sent as an array of parts, returned as that array. A streamed delta whose content is an array of parts is returned as its text in delta.content, and its Mistral thinking and Databricks reasoning parts as delta.reasoning_content, in the upstream's order. A part's signature has no field in a chat delta and is not returned.

This holds for every upstream that answers in the OpenAI Chat Completions format, including OpenAI-compatible providers, Azure OpenAI, OpenAI-compatible models on Vertex AI, and the Amazon Bedrock Chat Completions endpoint. Gemini on Vertex AI returns every candidate as a choice. /v1/messages and /v1/responses carry one answer per response, so they read only the first choice. When an answer's content is an array of parts, streamed or not, they return its text, and they return Mistral thinking and Databricks reasoning parts as reasoning: a thinking block on /v1/messages and a reasoning item on /v1/responses. See Mistral.

An output guardrail scans every choice, the refusal text, and legacy function_call arguments, and a masking guardrail rewrites them. It does not rewrite logprobs, so a caller that requests logprobs receives the upstream's token text unmasked. See Choices, Refusals, and Log Probabilities.

An answer the upstream has already served is not run again. When a model answers with a 2xx that AISIX cannot read, the caller receives 502, and AISIX does not retry the request, fail over to another target, or count the failure toward cooldown. The same applies to /v1/images/edits. An unreadable response from a credential exchange, such as an Azure AD or a Vertex AI service-account token request, is still retried and can still trigger cooldown, because it served no answer.

Legacy Function Calling

The deprecated functions and function_call request fields, and the function message role, work on every upstream. A functions or function_call sent as null is treated as absent.

• An upstream that speaks the OpenAI Chat Completions format receives the fields and the function turns exactly as sent.
• Claude on every platform, Gemini on Vertex AI, and every Amazon Bedrock model served through InvokeModel or Converse receive functions as tools, function_call as tool_choice, an assistant function_call as a tool call, and a function turn as that call's tool result.

When the caller declared functions and no tools, the answer comes back in the legacy shape: message.function_call, or delta.function_call on a stream, with finish_reason: "function_call". The legacy shape holds one call per turn, so only the first tool call of each choice is returned.

Requests That Now Fail

A gateway at 1.7.0 or earlier dropped or adjusted these parameters itself. They now reach the upstream, which answers for them:

• On Amazon Bedrock, stop on gpt-oss, Grok, and GPT 5.6 or later; the parameters the Chat Completions endpoint used to drop; strict on a tool for a model that does not take it; OpenAI fields that now reach a model's additionalModelRequestFields; an output limit below 16; and a request with no user or assistant message.
• On Gemini, the generationConfig settings and parametersJsonSchema that AISIX now sends, and a /v1/messages thinking.budget_tokens above a Gemini 2.5 model's thinking ceiling.
• On every translated path, a value the caller's protocol does not allow, such as a wrong-typed stop, max_tokens, temperature, tool_choice, reasoning_effort, or service_tier, a malformed tool, or a replayed tool call without its id or function name, which AISIX now refuses naming the field.

Other behavior a caller or operator can observe:

• A strict json_schema the caller sent reaches an OpenAI-compatible upstream unchanged, so an incomplete strict schema gets the upstream's validation error, as it would against the provider directly. AISIX closes a schema only when it set strict itself, translating a /v1/messages structured-output request.
• An assistant message with content: null is sent as null, and temperature and top_p keep the caller's decimal value.
• The caller's anthropic-beta header reaches Anthropic and Anthropic-compatible endpoints on /v1/messages. See Forward Client Headers.
• /v1/embeddings accepts token-ID input and forwards user and other fields. See Embeddings.
• A response-cache entry with more than one choice or with logprobs cannot be read by a gateway at 1.7.0 or earlier sharing the same Redis. See Share Cache Entries with Redis.

Next Steps

You have now seen how AISIX treats each request parameter. See Provider Compatibility for which endpoints each provider serves, and Proxy Errors and Retries for handling the errors described here.