Get Request
Look up one request by the id returned in its X-Request-Id response header.
Reports what the gateway knows about that request: the model and provider that served it, status, latency, tokens, cost, and every attempt made — so a retry or a fallback to another target is visible rather than inferred.
Requests refused before any model was called (rate limit, spend cap, empty
balance, model access) write no usage row, and are served from the request log
with outcome: "rejected".
Two surfaces are not resolvable here, because their usage is not recorded
against the HTTP request’s id: /v1/chat/compare, whose fan-out is recorded
per model under a derived id, and /v1/batches, whose usage is recorded
against the batch id — use GET /v1/batches/{batch_id} for those.
Resolvable for 90 days. Older ids return 404, as does an id belonging to another account — existence is never confirmed across tenants.
request_headers carries the HTTP headers of the request — what the gateway
received, and what it returned (the rate-limit state we reported, the request
id, the routing disclosure; never the provider’s own set). Credentials are
replaced at capture: Authorization, x-api-key, api-key,
x-goog-api-key and cookies report their NAME with a [redacted] value, so
“you sent no Authorization header” stays distinguishable from “you sent one”.
The client-IP forwarding chain is not reported. NULL when the request log no
longer holds the record — the rest of the payload answers regardless.
request_bodies carries the prompt and completion themselves, and is NULL
unless the key that made the request has opted in to exposing them — its own
policy governs, not the caller’s. It cannot be enabled for an organisation
with zero data retention on, which is also why a ZDR org has none to show.
Where PII redaction is enabled this is the REDACTED copy; the raw body is
never stored. A body over the size cap reports truncated: true with its
original size rather than being silently shortened.
No provider-side diagnostic is ever included. Error text is the same scrubbed message the original response carried.
Authorizations
Enter your MeshAPI key (rsk_...) or, for the admin-keys endpoints, a dashboard session token — sent as Authorization: Bearer <token>.
Headers
Dated version of the API contract to pin this request to. Omit it and the request is served under 2026-08 — the oldest supported version, so an existing integration is never moved by a release. A malformed or unsupported value is rejected with 400 invalid_api_version rather than falling back silently. The version actually served is echoed as X-Mesh-Version on every response, including errors.
2026-08, 2026-09 Path Parameters
Response
Successful Response
Everything we can say about one request id (MESH-768).
Carries UsageEventOut, never UsageEventDetailOut — error_detail,
provider_error_code, provider_request_id, upstream_status,
provider_requested and ip_address exist only on the admin subclass, so no
provider internal can reach a customer through this shape.
'success' | 'error' when a model was reached, 'rejected' when a gate refused the request before any model was called, 'pending' while the request's own usage row has not landed yet, and 'unknown' once it is too old to still be arriving — the attempts are reported either way.
How far back this endpoint can resolve a request id.
The id addressed more than one request, so attempts is omitted rather than guessed at. Only possible for requests made before the gateway began minting the id itself.
The request itself: the attempt that served it.
Every attempt including retried failures, oldest first.
attempt_count - 1.
Other billed rows this request produced (e.g. a memory embedding).
Populated only when ambiguous.
Populated only when outcome is 'rejected'.
The per-attempt waterfall (MESH-863). NULL when the request took one attempt, so there is nothing to draw.
The HTTP headers of the request, as the gateway received and returned them (MESH-835). NULL when the request log no longer holds the record, or is unreachable — the rest of the payload answers regardless.
The request and response BODIES, when the key or its org has opted in to storing them (MESH-856). NULL by default: body logging is off unless enabled, cannot be enabled under zero data retention, and expires on its own retention window before the rest of this payload does.