Is there a way to capture the full request body in API Management if the full request body is too large

Question

I am using Azure API Management (Developer/Premium tier) deployed in an Internal VNET. I am trying to capture the Request Body only when a backend error occurs (specifically 400 errors) . The request body is very large (1 mb - 10 mb). Is there a way to capture the request body and display somewhere in Azure? We do not have to record/save the body in some places, but we want to view the full request body when errors happen. It seems we cannot save full request body when its too large, so I'd like to know whether we have settings to only view the full request body. (The request body does not need to save in tables or insights, but whether we have streaming logs ) I can copy-paste from that after

Answer 1

Hi @jinxjer lee ,

Thanks for reaching out to Microsoft Q&A.

Unfortunately, Azure API Management cannot capture or display full large request bodies (1–10 MB), even conditionally on errors like 400. Logs and policies have strict size limits, so bodies get truncated.

Best approach is to log/store the full request body in your backend service (e.g., Blob Storage) and use a correlation ID from APIM to link failed requests to the stored payload.

1. Log full request body in the backend:
   • Move body capture out of APIM:
   • Your backend (App Service / Function / Container):
   • On 400 error =>store full request body in Azure Blob Storage, Database, Data Lake
2. Use correlation IDs:

In APIM:

<set-header name="x-correlation-id" exists-action="override">

• Log this ID in APIM logs/ Backend logs (with full body)
• Then correlate APIM =>“request failed”, Backend =>“here is the full payload”

3. Store payload externally before API call
   • Client uploads payload =>Blob Storage
   • API call sends only Blob URL / ID
   • Backend retrieves payload if needed
4. Partial logging in APIM

• You can log first 32–64 KB of body, Content-Length, Hash (SHA256). This gives Debug clues, No risk to gateway

Hope this helps!

---

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.

Answer 2

Capturing large request bodies in Azure API Management is constrained by the same limits regardless of whether the data is ultimately stored or just inspected. There is no separate “streaming logs” feature that bypasses body-size limits only for viewing.

However, request bodies (including large ones) can be captured and sent out of API Management for inspection using policies such as log-to-eventhub, with some important considerations:

1. Use log-to-eventhub and buffer the body
   • API Management can send request/response data to Azure Event Hubs via the log-to-eventhub policy.
   • When reading the body in a policy and still allowing the backend to read it, the body must be buffered by calling As<string>(true):

          context.Request.Body.As<string>(true)
     

   • Passing true causes the body to be buffered so it can be read again by the backend.
   • This is explicitly called out as important when dealing with large uploads or long polling.
2. Be cautious with very large bodies
   • The documentation notes that for APIs that upload large files or use long polling, it is best to avoid reading the body at all, because buffering large bodies has performance and memory implications.
   • This means that while it is technically possible to read and log large bodies, it may not be advisable for 1–10 MB payloads at high volume.
3. Correlate request and response for error scenarios
   • A common pattern is to generate a message-id using a set-variable policy:

          <set-variable name="message-id" value="@(Guid.NewGuid())" />
     

   • This ID is then included in both request and response messages sent to Event Hubs, allowing correlation of failed responses (for example, HTTP 400) with their original requests.
   • The complete policy configuration uses log-to-eventhub in both <inbound> and <outbound> sections, with the shared message-id variable.
4. Where to “view” the body
   • API Management itself does not provide a built-in UI to view arbitrarily large full request bodies on demand.
   • Instead, the recommended approach is to:
     • Send the full HTTP message (including body) to Event Hubs using log-to-eventhub.
     • Consume the Event Hub stream with a downstream tool or service (for example, a custom consumer, logging/monitoring service, or third-party tool) where the full body can be inspected.
5. Observability options and trade-offs
   • API Management supports multiple observability integrations: built-in analytics, Azure Monitor Logs, Application Insights, and logging through Azure Event Hubs.
   • For custom scenarios like “view full request body only on errors,” logging through Azure Event Hubs is the recommended extensible mechanism.
   • None of these integrations provide a special “view-only, no-storage” mode that bypasses the underlying body-size and buffering constraints.

In summary, there is no separate streaming-view feature that avoids the limits on large bodies. To inspect full large request bodies on 400 errors, configure policies that:

• Generate a correlation ID (set-variable).
• Use log-to-eventhub and context.Request.Body.As<string>(true) to send the body to Event Hubs when the backend response status is 400.
• View the body via an Event Hubs consumer or downstream logging system, while being mindful of performance and memory impact for large payloads.

---

References:

• Monitor your APIs with Azure API Management, Event Hubs, and Moesif
• A policy to send application/HTTP messages
• Observability in Azure API Management
• Set body