X-Request-Id

Tracing & Correlation de facto — unregistered response 3 spellings

X-Request-Id is the identifier you quote when you write to support. It ties a single call to a line in the provider’s logs, and without it a debugging conversation is two parties describing roughly-similar events to each other.

Sixty-eight providers declare it. Its close sibling X-Correlation-ID appears in 20 — spelled five different ways. traceparent, the W3C standard that actually solves distributed tracing properly, appears in six.

That ordering is the whole story of header standardisation in one line: the ad hoc convention has eleven times the adoption of the specification designed to replace it.

The registry

Not registered with IANA. It is a de facto or vendor field — real, widely used, and governed by nothing but convention.

In the catalog

Declared by 68 providers across 8,545 published specification files in the API Evangelist catalog, where it appears as a response header — sent by the server.

It is spelled 3 different ways across those contracts — X-Request-Id, X-Request-ID, x-request-id. HTTP field names are case-insensitive (RFC 9110, §5.1), so every one of these is the same header. They are not the same string, which is why generated clients disagree about it.

Using it

Generate one if the client did not send one, echo it on every response including errors, and put it in the error body as well — an agent parsing a failure should not have to correlate headers and body to file a useful report. If you are building new, send traceparent alongside it; the standard only wins if people ship it.