{"version":"2.1.311","anchor":"gateway-forwards-a-cloud-request-id-from-the-apim-request-id","canonical_anchor":"gateway-forwards-a-cloud-request-id-from-the-apim-request-id","heading":"Gateway logs now record a second upstream request ID","tier":"internal","area":"Gateway","scope":"org","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.311\/e\/gateway-forwards-a-cloud-request-id-from-the-apim-request-id","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.311","markdown":"### Gateway logs now record a second upstream request ID\n\nThe gateway now captures the upstream `apim-request-id` header, logs it, and strips it and the existing request ID from responses\n\n**Unclear.** Whether this gateway runs for ordinary Claude Code users is not stated.\n\n**What**\n\nThe gateway previously captured only the upstream `request-id` header. It now also copies the upstream `apim-request-id` header into `x-gateway-upstream-cloud-request-id`.\n\n- The value is checked against a pattern and logged as `upstream_cloud_request_id` on the line recorded for each model request.\n\n- Both `x-gateway-upstream-cloud-request-id` and `x-gateway-upstream-request-id` are removed from responses before they go out.\n\n**Why**\n\nWhen a request fails at a cloud service that sits in front of the model, such as Azure, the logs now hold an ID that can be matched with that service's own records.\n\n- Area: Gateway\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 2\/5\n- Scope: org\n- Heads-up: no"}