Network bodies · Android SDK · Docs

The actual payloads, when you need them. Off by default, on both sides of the gate.

A network breadcrumb tells you a request returned 500. A body tells you what it returned. That is worth a lot in triage, and it is the most sensitive thing the SDK can capture — which is why it is off by default and gated twice.

Enabling

Server first, in the dashboard. The SDK reads it from GET /api/config. Then, on the client, three things must be true:

the OkHttp interceptor is attached to the client
capture.network is true — it is false by default
capture.networkBodies is not false

TraceItXConfig(appId = "txx_app_…", sdkKey = "txx_live_…", capture = CaptureConfig(network = true))

A client can always turn this off and can never turn it on. If you have a contractual reason bodies must not be captured in a particular build, set networkBodies = false and it is off regardless of server state.

The allowlist

bodyContentTypes is an allowlist, not a blocklist. A body whose content type is not listed is never read — not read then discarded, not truncated. That is what keeps image downloads and binary streams out of reports entirely, rather than relying on a size check to catch them.

What arrives

Response bodies only. The Android SDK does not capture request bodies: a second read of a caller-supplied RequestBody cannot be guaranteed prompt, and delaying your request is never an acceptable price for a bug report.

{
  "ref": 17,
  "t": 1765800000123,
  "resBody": "{\"error\":\"cart_empty\"}",
  "resBodyTruncated": false,
  "resBodyBytes": 24
}

ref joins to the network breadcrumb’s data.reqId. Bodies live in payload.networkBodies, deliberately not inline on the crumb — a receiver that only wants the timeline never has to parse them.

Why a body is missing

`resBodySkipped`	Meaning
`content-type`	Not on the allowlist.
`unsupported`	The response reached the interceptor still compressed — your client sets its own `Accept-Encoding`, so OkHttp did not decode it.
`error`	Reading it failed.

A missing body with no skip reason means the response genuinely had none, while content-type means there was one and policy declined it.

Android specifics

The body is teed, not pre-read: the SDK copies bytes as your code consumes the response and never reads ahead of it, so a streaming response is never exhausted on your behalf. The flip side is that a body your code never reads is never captured.

Byte caps and the total budget are in Server config.