Inferock
Documentation menu
Development guide

What the gateway forwards

This page lists exactly what we send, what we change, and what we leave out on purpose.

10 / 10

When you send a call through Inferock, we do not pass your request headers straight through to the model provider. For each route we build a new, short list of headers. This page lists exactly what we send, what we change, and what we leave out on purpose.

This page covers the headers and the body we send upstream. Streaming is chosen by the stream field in your body, never by a header. On the way back, for calls with your own key we return the provider's response headers except content-encoding, content-length, transfer-encoding and any access-control- header; on managed Inferock Serve we return only content-type, cache-control and retry-after.

Calls to Claude models with your own key

This covers both ways of calling a Claude model: the messages route (POST /v1/messages) and the chat completions route (POST /v1/chat/completions).

We send these headers:

  • x-api-key: the provider key you saved with us. Your Inferock key is never sent.
  • content-type: always application/json.
  • anthropic-version: on the messages route we send the value you sent, or 2023-06-01 if you sent none. On the chat completions route we send the value you sent when it is written as a date such as 2023-06-01, or 2023-06-01 if you sent none or sent a value in another form.
  • anthropic-beta: we now send it when every value in your list is valid; if any value is not valid we leave the whole header out and the call still runs. This is new and we have not yet checked it end to end on the live service; we will update this page when that check is done.

We leave out every other header you send, for example accept, user-agent, idempotency-key, x-request-id and any custom x- header. We do not add any application headers of our own. The only other headers on the call are the standard transport headers every HTTP client sets, such as host and content-length.

Calls to other models with your own key

  • Models that use the chat completions request format: we send authorization with the provider key you saved with us, and content-type: application/json.
  • The responses route (POST /v1/responses): we send authorization with the provider key you saved with us, and content-type: application/json.
  • Gemini models: we send x-goog-api-key with the provider key you saved with us, and content-type: application/json.

Nothing else from your request headers is sent.

Calls on managed Inferock Serve

  • We send authorization with our own key for the hosting partner, and content-type: application/json.
  • Your Inferock key and your request headers are not sent to the hosting partner.

Calls on our encrypted routes

  • We relay only the framing headers the encrypted connection needs, we add authorization with our own key for the enclave host plus the headers that host requires for routing and metering, and we pass your encrypted request through unchanged, byte for byte. We cannot read it.

The request body

  • On our standard routes we read your JSON request and write it out again before we send it, so the bytes may differ, for example in spacing or the order of fields. We also make the changes listed below, and no others.
  • On both Claude routes, when the model name is a Claude 4.7 or later 4 series name or a Claude 5 series name, we remove temperature from the body.
  • On the chat completions route to a Claude model, we build a new messages format request from these fields only: model, messages, max_tokens (or max_completion_tokens; if you send neither we set 1024), stream, temperature, top_p, stop (sent as stop_sequences), tools and tool_choice. System messages are joined into the system field. Any other field is left out.
  • On the chat completions route to other models: when stream is true we set stream_options.include_usage to true; for reasoning model names we move max_tokens to max_completion_tokens and remove temperature; we remove metadata unless store is true.
  • On the responses route we move max_tokens to max_output_tokens and translate response_format into text.format.
  • For Gemini models we translate your request into the Gemini generate content format.
  • On managed Inferock Serve, when stream is true we set stream_options.include_usage to true, and we set max_tokens or max_completion_tokens to the model's published ceiling when you send none or a higher value.