Headers and request IDs
This page lists what Mubit does with each header on a model call, and the headers it adds to the answer. Use it when you debug a call, or when you need to quote a call's ID.
Headers Mubit reads
Mubit reads two optional headers from your request. It doesn't send them to your provider.
| Header | Values | What it does |
|---|---|---|
x-middleware-record | full, metadata, off | How much of the call Mubit keeps. |
x-middleware-store | false, 0, off, no | The same as x-middleware-record: metadata. |
What Mubit records says what each level keeps and what a lowered call gives up.
Headers Mubit changes or drops
| Header | What happens |
|---|---|
Your Mubit key (Authorization, x-api-key, x-goog-api-key) | Taken out. Mubit sends the provider key, or your Neon token, in the header the provider expects. |
Any header that starts with x-middleware- | Not sent to the provider. |
| Cookies, in either direction | Not passed on. |
forwarded, x-forwarded-for, x-real-ip, via | Not passed on. |
accept-encoding | Set to identity, so the answer is not compressed. |
Mubit passes most other headers as you sent them: content-type, accept, user-agent, idempotency-key, x-client-request-id, anthropic-version and anthropic-beta, and the headers the provider SDKs add.
Send your Mubit key only in the header your provider's SDK uses for its key. A call that carries it anywhere else, such as a second header or the path, gets 401 middleware_key_refused. For Gemini, send the key in the header, not in ?key=.
Headers Mubit adds to the answer
| Header | On | What it says |
|---|---|---|
x-middleware-request-id | Every answer: a success, a stream, your provider's error and Mubit's own error | The call's ID in Mubit. |
x-middleware-served-by | An answer that an adapter gave | Who answered: the value names the version that answered, as version=<n>. An answer from your provider doesn't carry it. See Calls answered by an adapter. |
x-should-retry | Mubit's errors that a retry won't fix, such as the key errors | false. |
retry-after | Mubit's 429 and 503 errors | Seconds to wait before you try again. |
Your provider's own headers, such as its request-id, x-request-id and rate-limit headers, pass unchanged beside them.
The request ID
The request ID starts with mreq_ and has 32 hex digits after it. IDs sort by time. Mubit's own errors carry the same ID in their body, as request_id.
Quote the request ID when you ask for help with a call. It identifies the call without exposing its content. Don't send a key.
To read it:
raw = client.chat.completions.with_raw_response.create(
model="gpt-6-luna",
messages=[{"role": "user", "content": "Reply with the word ok."}],
)
print("request id:", raw.headers.get("x-middleware-request-id"))
response = raw.parse()The Python and TypeScript examples use the client from Connect OpenAI. In curl, -i prints the answer's headers. The header works the same way on every provider prefix.
An answer without x-middleware-request-id didn't come through Mubit's API. Check the base URL.
Requests in the console shows its own ID for each call, under Details. It isn't the request ID your app gets: see Find a call's request ID.
Runtime calibration routes use a different ID, in x-request-id: see Runtime calibration.