Log the request-id response header when troubleshooting S2S API errors

When investigating S2S API failures such as 5xx responses or timeouts, log the request-id value returned in the API response headers when a response is received.

What to log

• request-id from the response headers, if present
• cf-ray from the response headers, if present
• The exact request timestamp, preferably with milliseconds and timezone
• The full endpoint path that was called
• Whether the request returned an HTTP error or timed out on the client side
• The affected player identifier, when available

Important note for timeouts with no response

If the request times out before any response is received, there may be no headers to log. In that case, request-id and cf-ray will be unavailable because no response arrived.

For these no-response timeouts, capture as much of the following as possible instead:

• Exact timestamp with milliseconds and timezone
• Full endpoint path
• Whether the timeout happened while connecting or while waiting for the response
• Source IP address of the caller, if available
• The affected player identifier or equivalent request identifier
• A few consecutive examples around the same time, including both successful and failed requests when possible

Why this helps

The request-id header is the primary value support uses to trace a specific API request on the backend when a response was returned.

If no response was returned, support may need to correlate requests using the timestamp, endpoint, source IP, and player identifier instead. Providing nearby successful and failed examples can also help determine whether the request reached edge infrastructure or stalled before a response was sent.

Example response headers

request-id: b5ed7d1e-12fd-4a19-827b-a4e0322e284f
cf-ray: 9ff860476b5a30da-ICN

If multiple headers are present, the most important one for backend investigation is request-id.