A customer emails you a screenshot of a 500 error. It has no timestamp you can trust, no request identifier, and a redacted URL. Somewhere in your logs is the request that produced it. Finding that request is, for most teams, an afternoon.
Why the afternoon happens
Gateway access logs record that a request occurred. Application traces record what your code did with it. The two are joined by a timestamp and a path, which is exactly the join that fails when a customer is in a different timezone and your path contains an identifier you have never seen.
- The customer's clock is wrong, or their screenshot is from yesterday.
- The path template is parameterised, so the log line does not match the URL they sent.
- The interesting part — the request body — was never captured, because capturing bodies in a gateway is a compliance conversation nobody wanted to have.
The identifier changes everything
The fix is boring and it works: put a stable identifier in every response, including error responses, and make it searchable. Once the identifier exists, the support conversation stops being archaeology. The customer pastes it, you open the record, and you are reading the exact bytes they sent.
The identifier is not the clever part. Making it survive an error path, a retry and a proxy is the clever part.
What to capture
Capture the request line, the headers you control, the body after redaction, the response status and body, and the timing breakdown. Redact at the edge rather than at rest — the point is that the sensitive field never leaves the boundary, not that it is encrypted once it has.
Then give it to the customer
The last step is the one most teams skip. If an integrator can look up their own requests, roughly a third of the tickets are never filed. That is not a support improvement; it is a product feature, and the teams that ship it are the ones whose APIs feel trustworthy.