The Request Id Rides Twice: Every API Response Carries It in a Header and in Its Own JSON Body

I work on OnePassApps, the team behind app.onepassapps.com. This measures our own API host over plain HTTPS on 8 November 2026 - no browser, no session, no JavaScript.

Every route answers with the same three keys

I called the 7 live routes on api.onepassapps.com with an Origin of https://app.onepassapps.com. Every one of them answered 200 with application/json, and every one of them has the same three top-level keys:

• ok
• data
• meta

The data key is different on every route - it is the route's own payload, from 410 bytes on /api/health to 15,650 bytes on /api/products. The other two keys are the same everywhere.

The id is in the header and in the body

Each response carries an x-request-id header. And the meta object in the JSON body carries a requestId field.

On 7 of the 7 routes I measured, the two are the same string. The server does not stamp an id in one place and a different one in the other - one id, sent twice, in two different places in the same response.

The shape of it is fixed: req_ followed by 16 characters drawn from letters, digits, underscore and hyphen. The 7 ids I collected from 7 different routes were 7 distinct values - no two routes shared one.

Two consecutive calls to the same route get different ids. I fetched /api/health twice in a row and got req_pKFq6dWMQEOiu4x_ and then req_wOG6LWg4WfQzDEQl. The id is per request, not per route.

The error answer keeps the same shape

A route that does not exist answers 404 with a body of 124 bytes:

{"ok":false,"error":{"code":"NOT_FOUND","message":"That route does not exist."},"meta":{"requestId":"req_oEtP8l75UI5DYnHC"}}

The error body has three top-level keys too: ok, error and meta. The ok flips to false, the data key is gone, and the error object carries a code of NOT_FOUND and the message "That route does not exist.". The meta object still carries a requestId - and it matches the x-request-id header on that same response, the same way it does on a success.

So a client can correlate a failure with a request id exactly the way it correlates a success, without a second code path to learn.

The counters ride alongside

Every one of these responses also carries the request's position against the route's own limits:

• x-ratelimit-limit and x-ratelimit-remaining
• x-concurrency-limit and x-concurrency-remaining

They differ from route to route, so the route's own budget is readable from the response without a second call.

What I did not do

One build, one network, one day - 8 November 2026 - plain HTTPS from one machine, signed out, no browser and no JavaScript. The 7 routes are the ones I know about and called; this is not an inventory of the API. I sent one GET per route plus the two repeat calls to /api/health, so I have not tested how the id behaves across a retry, a failure in the middle of a request or a long-running request, and I did not test any authenticated route. I am not claiming what any client or log pipeline does with the id, only what the server returned.

The app the API belongs to: https://app.onepassapps.com?utm_source=devto&utm_medium=post&utm_campaign=request-id-twice&utm_content=home-link
The app's own guides: https://app.onepassapps.com/guides?utm_source=devto&utm_medium=post&utm_campaign=request-id-twice&utm_content=guides-link