Read response headers beside the HTTP status and raw body. They can describe the representation, timing, retry guidance or provider request metadata; they cannot tell you whether the response content itself is correct.
Standard HTTP response fields
These four fields have HTTP semantics. A provider may omit a field when the protocol permits it, and an HTTP client may normalize what it exposes.
On a phone, swipe the table horizontally to read all five columns.
| Header | Official meaning | When to inspect it | What to do with the value | Field class |
|---|---|---|---|---|
Retry-After | A server’s requested wait before a follow-up request. RFC 9110 defines its use for 503 and redirects; API providers may also document it for other statuses.RFC 9110 §10.2.3 OpenRouter retry guidance | A response asks the client to wait, especially a documented rate-limit or temporary-unavailable response. | Keep the status and error body with it. OpenRouter documents this field on 429 and 503, and on a specific 402 in-flight-budget error. Honor only the provider’s status-specific retry rule; do not retry a permanent error just because a value is present. | Standard HTTP field |
Content-Type | The media type of the message representation, such as application/json or text/event-stream.RFC 9110 §8.3 | A parser rejects the body, the response looks like HTML, or you need to distinguish JSON from an SSE stream. | Compare the declared type with the raw body and expected endpoint. It describes how to process the representation; it does not prove that JSON is valid, a stream finished, or the content is correct. | Standard HTTP field |
Transfer-Encoding | For HTTP/1.1, transfer codings applied to the message; chunked frames an unknown-size body as length-marked chunks.RFC 9112 §§7.1, 8 | You have a raw HTTP/1.1 wire capture and need to check message framing. | Chunked framing alone does not mean truncation or an application-level stream. In a raw chunked message, the zero-sized final chunk closes the framing; its absence makes that HTTP/1.1 message incomplete. HTTP clients often decode framing before exposing the body. | Standard HTTP field |
Date | The HTTP message’s origination date and time. RFC 9110 says senders should use their best available approximation. RFC 9110 §6.6.1 | You are correlating a response with a local incident time or provider support records. | Treat it as approximate message timing, not an exact model-generation timestamp. Keep your own UTC time of the request as a separate field. | Standard HTTP field |
Provider-specific response fields
These names are defined by a provider’s API documentation, not by the general HTTP standard. The examples below are limited to response headers OpenAI currently documents; another provider or gateway may use different names or forward none of them.
On a phone, swipe the table horizontally to read all five columns.
| Header | Official meaning | When to inspect it | What to do with the value | Field class |
|---|---|---|---|---|
OpenAI: x-request-id | OpenAI documents this response header as a unique identifier for an API request used in troubleshooting. OpenAI API overview | A response arrived and you need to give OpenAI support an exact request to trace. | Copy the exact value with the UTC time, endpoint, status and requested model. Do not substitute your own client ID or assume another provider uses this name. | Provider-specific response field |
OpenAI: x-ratelimit-* | OpenAI documents request- and token-limit fields including x-ratelimit-limit-requests, x-ratelimit-remaining-tokens and reset fields.OpenAI API overview | A request is rate-limited or you need to understand the limit information returned with that response. | Record only the fields actually returned. Treat remaining and reset values as provider-specific metadata for that route, not universal quotas or proof of service availability. | Provider-specific response field |
OpenAI documents x-request-id in the response headers, not as a JSON response-body field. Do not infer that OpenAI’s request-ID or rate-limit names are also OpenRouter response headers. Check the documentation for the exact route you called. OpenRouter: API errors and debugging
Use headers with the response, not instead of it
- Start with status and body. A header can help explain how to handle the response, but headers alone contain no JSON or SSE answer to validate.
- Keep wire framing separate from application streaming. HTTP/1.1 chunked framing is a transport mechanism. SSE events and Chat Completions finish markers are in the response body.
- Preserve evidence before retrying. Save one redacted capture first; repeated retries can change the status, request ID and rate-limit values.
Use the raw-response capture steps to collect all three parts. If the body is an SSE stream, continue with stream-stall diagnostics. When a reproducible issue needs support, add the provider ID only in its documented location to a redacted provider report.
Official provider references
OpenAI API overview: request IDs and rate-limit response headers
OpenRouter API errors: Retry-After behavior and status-specific guidance
Standards and provider documentation checked 20 October 2026. No request was sent to a model endpoint.
Free API access and limits
Check the site free API access and limits before trying to obtain a site key. Read the current status and request limits before using a site key. It is not a source of official provider keys.
ChinaGenAI is not affiliated with the providers named here. This release contains setup guidance and explicitly labeled fictional examples, not claimed live model benchmarks.