Request ID (correlation ID)

A request ID is generated at the edge — by the load balancer, the gateway or the first service — and returned in a response header such as X-Request-Id. Every log line written while handling that request carries it, and when the request fans out to other services the ID travels with it, so the whole path can be reassembled later.

How it works

Clients should log the ID with any error they report, and include it in bug reports; support can then find the exact server-side logs in seconds. Distributed tracing standards such as W3C Trace Context (the traceparent header) formalise the same idea, adding parent and child spans for timing.

The misconception

That a timestamp and an endpoint are enough to find a request in the logs. On a busy system there are thousands of identical calls per second. Without the ID, "it failed around 10:42" is a search, not a lookup.

Try it here

The live backend sets an X-Request-Id header on every response and includes the same requestId in JSON bodies — including in its 500 errors, where it is the only detail it exposes.

Related

• HTTP 500 Internal Server Error
• HTTP headers

Sources

• Traces and context — OpenTelemetry

Other terms

• HTTP headers — Name–value metadata sent with every request and response, separate from the body.
• Webhook — An HTTP callback the server sends you when something happens, instead of you polling to ask.
• HMAC signature — A keyed hash proving a payload came from someone holding the shared secret and has not been altered.
• Server-Sent Events (SSE) — A one-way stream of events from server to client over an ordinary HTTP response that stays open.

All glossary terms · Testing techniques · All 39 mock REST APIs

Last updated 16 October 2026