Request Inspector & Decoding

Every captured request/response pair can be opened in the request inspector, a full-screen dialog for examining method, target, headers, and bodies. Opaque bodies — base64 blobs, gzip payloads, MessagePack, protobuf, or vendor-specific encodings — are made readable through decode pipelines: ordered lists of transform stages applied one after another until the body is legible.

Open the request inspector

Click any request row in the API workspace route catalog, in global search results, or in signature analysis (see /docs/en/api-re/). The inspector opens with:

• A header showing the method badge, host, path, query string, and response status badge.
• A metrics strip: Capture (session name), Frame (f<req>->f<res> packet frames), Protocol, Stream (tcp N / h2 M), Duration, and Body sizes (req X / res Y).
• Prev/next arrows with an n/total counter to walk through the result list without closing the dialog.
• Actions: Bookmark, copy request URL, Baseline/Candidate (set the compare anchor), TLS (open the linked ClientHello fingerprint), and Minimize (open the request minimizer).

The body of the dialog is a tabbed view of the exchange. Press number keys to switch tabs:

Credential headers and sensitive URL values are masked by default. The copy action is labeled Copy redacted request URL until you explicitly reveal secrets; Copy as cURL and Copy Wireshark filter live in the same menu.

Decode a body manually

Each body pane (request and response) has three controls: a Decode selector, a Type (syntax) selector, and a Beautify toggle. The default decode mode is route — apply the route’s saved pipeline, if any. Picking any other mode is a manual one-stage override.

Available decode modes:

The Type selector controls syntax highlighting and beautification: text, json, xml, html, javascript, css, yaml, toml, graphql, form, csv, binary (hex dump).

When the decode mode is raw, the inspector auto-detects common formats and applies them unless you have manually overridden the pane: gzip magic bytes, MessagePack/CBOR/BSON/protobuf heuristics, JWT-shaped text, and encoded payloads (base64, base64url, base32, hex, quoted-printable, Ascii85, percent-encoding, rot13, and Group-IB packets starting with 004/MDA0). A successful detection also sets the syntax mode and enables Beautify.

How decode pipelines work

A decode pipeline is two ordered stage lists — one for requests, one for responses — bound to a route. Stages run sequentially; binary output from one stage (for example, gunzipped bytes) is carried into the next stage as bytes, not lossy text, so chains like base64 → gzip → json work.

Route resolution for mode route:

1. Exact endpoint key — METHOD:host/pathTemplate, e.g. POST:api.example.com:/v1/events.
2. Route pattern — pipelines whose host and method match and whose path template matches segment-by-segment ({id} matches any single segment). Candidates are sorted by template specificity, then by last update time.

Besides the built-in modes above, a stage can be script:<id>, a sandboxed custom JavaScript decode function — see /docs/en/collector/. A protobuf stage uses the endpoint’s bound protobuf schema when one exists (including per-frame decoding of gRPC streams), and a pipeline may reference a protobuf schema directly. A pipeline cannot contain a route stage — route rules do not recurse.

Every decode carries provenance: the source (raw, manual, or route-rule), each applied step with its mode and input/output byte lengths, and the schema used. Decode errors never embed body contents and are truncated to 300 characters.

[!NOTE] Truncated captured bodies are decoded best-effort, but schema-based protobuf decoding is refused on truncated input because the result would be unreliable.

Compose a pipeline in the editor

1. Open the API workspace and expand a route in the catalog.
2. In the route’s detail area, find the Decode pipeline panel.
3. Under Request or Response, use the Add step selector to append stages. Built-in modes are listed first; registered custom scripts appear under Custom scripts as script: <name>.
4. Remove a stage with the × on its badge; order is the order of addition.
5. Watch the live Request preview / Response preview panes, which run the unsaved pipeline against the route’s first sample hit and show the provenance line (source · stage → stage · schema …). Previews stay secret-redacted until you reveal secrets.
6. Click Save to persist, or Clear to delete the pipeline for this route.

[!TIP] If the existing pipeline fails to load, the editor disables Save and shows a Retry button, so a transient backend error cannot overwrite a working configuration.

Registration and persistence

Saved pipelines are stored server-side in the SQLite table decode_pipelines, keyed by endpoint_key (upsert on conflict), with columns for host, method (uppercased), path_template (defaults to /), request_modes_json, response_modes_json, protobuf_schema_id, and an RFC 3339 updated_at timestamp. The REST surface is:

GET    /api/decode-pipelines            # list all pipelines
POST   /api/decode-pipelines            # create or update (upsert by endpointKey)
GET    /api/decode-pipelines/{endpointKey}
DELETE /api/decode-pipelines/{endpointKey}

On startup the frontend loads five registries independently — decode pipelines, decode scripts, protobuf schemas, protobuf bindings, and route-model rules. Each resource that loads successfully becomes usable immediately; a failed resource is retried on the next attempt without discarding the ones that already loaded, and a banner lists any resources that could not be fetched.

Copy and export decoded content

The Copy menu on a body pane offers:

The interface options appear only when the decoded body is valid JSON. At the request level, the inspector’s copy menu provides the (redacted or revealed) request URL, a cURL command, and a Wireshark display filter for the exchange.