Panels

Network

Every OkHttp call your instrumented client makes is recorded and listed here, newest first, and it survives closing the app. This is the panel most people open first, usually to settle the question of whether the app sent the wrong thing or the server sent it back.

What is captured, and what is not

Capture happens in the interceptor you added to your OkHttpClient, so the panel sees exactly the calls that went through that client — and nothing else. Traffic from a WebView, from another HTTP library, or from an OkHttpClient built somewhere you forgot to instrument will not appear. If a call you expected is missing, that is almost always the reason.

For each call you get the method, scheme, host, path, protocol, status, duration, request and response content types and payload sizes, the full headers on both sides, and the bodies up to the configured capture limit.

Request headers come off the wire

The headers shown are the ones that actually went out, not just the ones your calling code set — an Authorization header added by a downstream interceptor, a token refresh, or OkHttp's own bridge is included. How that works is on the install page, and it is the reason exports need care before you share them.

Finding the call you want

On a busy app the list fills up fast, so it is built list-first: filter down, then open one call.

Filters by method, host, outcome, and time window — "only errors in the last five minutes" is two taps.
Search across endpoints, headers, bodies, and the generated cURL command. Searching the body is what makes it possible to find a call by an order id you saw on screen.

A call whose response came from a mock rule carries a MOCK badge in the list, so a surprising response is never mysterious — see Mocks.

Two different empty states tell you which situation you are in: a fresh install with nothing captured shows a "No API calls yet" card, while a filter or search that matches nothing shows a distinct "No matching captures" card. You never have to guess whether the list is empty or just filtered.

Reading a call

Tapping a row opens the detail screen, which has four tabs — Overview, Request, Response, Tools. As on the main panel, you can swipe left and right between them instead of aiming at the tab bar.

Overview — the summary line, timing, sizes, and the query parameters split out. Tap any row to copy its value.
Request and Response — full headers, then the body. JSON and XML are pretty-printed, with a raw fallback when the payload is not what its content type claimed.
Tools — copy or share the URL, headers, body, cURL command, or the whole event; export; and build a mock rule from this call.

Large bodies are rendered in chunks so scrolling stays smooth, and there is a find-in-body search inside the body card. When a payload is genuinely big, hand it to the value viewer instead: a real JSON tree with collapse and expand, child counts, and search that does not block while you type.

Quick actions from the list

You do not have to open a call to act on it. Long-press a row for Copy URL, Copy cURL and Share cURL. You can also select several calls and share them together, or share the whole filtered list at once, as cURL, TXT or HAR.

Turning a captured call into a mock

Mock this response on a captured call prefills a rule from what the app actually received — same method, same URL, same status, same body. It is the fastest way to freeze a real response and then edit it into the case you actually want to test. Response mocking covers what happens next.

Exporting

Two formats, both covering the calls currently visible after filtering:

Format	Contains	Good for
`.txt`	A readable log of each call including its full cURL command, and a `Mock:` line naming the rule where one fired.	Pasting into a ticket, or handing to someone who wants to reproduce a single call.
`.har`	Standard HAR 1.2.	Opening in browser DevTools or Proxyman and using their tooling on a capture from a phone.

Exports are written to a private cache directory and shared through a non-exported FileProvider, so nothing is world-readable. The library never uploads them anywhere; a file leaves the device only when a person taps share.

Exports contain real credentials

A HAR, TXT or cURL export carries the same Authorization headers, API keys and cookies the original requests used — including ones your own code never set. Redact before attaching one to a ticket. The QA checklist is a short, practical procedure for this.

Watching traffic without the inspector open

AppInspect can post a notification per captured call showing just the method, status code, host and path. Tapping one opens the inspector on that exact request. Mocked calls are distinct in the shade: a MOCK · title prefix and an amber tint.

On Android 13 and newer this needs a runtime permission that your app has to request — AppInspect cannot prompt for it. See Network notifications.

How long calls are kept

Captured events are persisted in AppInspect's own app-private SQLite database, so they are still there after the app restarts. The default cap is 300 events; when it is reached the oldest are dropped. Clearing captured data from inside the inspector removes them immediately.

Two consequences worth knowing. In debug builds that database can contain captured auth headers, so if your app enables Android auto-backup you may want to exclude it — the QA checklist has the detail. And in release builds it is never created at all: see the security model.

Turning it down

You can hide the panel entirely with AppInspectPanels(networkEnabled = false), mask sensitive header and body values with showRawSensitiveValues = false, or keep capture on and just switch notifications off. All of it is on the configuration reference.