Global Search

Search URLs, headers, bodies, and credential-bearing traffic across captures.

Global search runs over every capture currently enabled in the API lab and matches your terms against the request line, headers, and decoded bodies of each exchange in a single pass. It is the fastest way to locate a specific call, a leaked value, or every request that carries credentials before you move into replay or investigation.

  1. Open the API lab view (see /docs/en/api-re/).
  2. Select the Search tab (the second tab, after Catalog).
  3. Type into the search field — placeholder: Search URL, headers, decoded bodies, status….

The panel searches the captures selected for the API lab, not the entire capture library. Enable a capture in the library first if its traffic does not appear.

What is indexed

Each exchange is scanned across six fields. A hit reports which fields matched:

Field labelContents searched
urlMethod, authority (host), path, query string, and the full URL
statusNumeric status code and status text (e.g. 404 Not Found)
request headersEvery request header line, in captured order
request bodyThe decoded request body text
response headersEvery response header line
response bodyThe decoded response body text

Body fields contain the decoded text produced by the capture’s decode pipeline, so searching reaches inside JSON, form, and other text payloads. Exchanges whose bodies were not decoded as text are only searchable through their other fields.

Query syntax

The query is plain terms, not a regular expression:

  • Split on whitespace into tokens. An empty query matches nothing on its own — combine it with filters to list exchanges by attribute (see below).
  • AND across tokens: every token must occur somewhere in the same exchange. Terms may land in different fields — orders 500 finds an exchange whose URL contains orders and whose status is 500.
  • OR across fields: a token matches if it appears in any of the six indexed fields. The chips on each result mark the fields where all terms co-occur within that one field.
  • Matching is case-insensitive.
  • Both the query and the indexed text are normalized the same way, so punctuation and URL encoding do not have to be exact. Normalization strips http:///https:// schemes, treats runs of % / ? # & = : . \ _ - as separators (or removes them), rewrites %2f to / and %3a to :, and percent-decodes values when possible.

Because of that normalization, all of these queries find https://api.example.com/v1/users:

api.example.com
api example com
api/v1/users
APIEXAMPLECOM

Filter results

Filters apply on top of the text query — an exchange must pass every active filter and the term match to appear.

ControlValuesBehavior
MethodGET, POST, PUT, PATCH, DELETE, OPTIONSExact method match (case-insensitive)
Status2xx, 3xx, 4xx, 5xxMatches the status class; exchanges with no recorded status are excluded
Host contains…Free textCase-insensitive substring match on the authority (host)
Credential trafficCheckboxKeeps only exchanges that reference secrets (next section)

The search library also accepts a contentType substring filter, but the panel does not expose a control for it.

With an empty query, filters alone drive the result list: for example, Status = 5xx with no terms lists every server-error exchange across the enabled captures. The summary line under the toolbar reports {n} results across {m} exchanges.

Find credential-bearing traffic

Tick Credential traffic to restrict results to exchanges that carry secrets. An exchange qualifies when either condition holds:

  • A request header name matches authorization, cookie, token, secret, api-key, or api_key (case-insensitive).
  • A query parameter name ends in token, secret, key, or sig, or is exactly code — e.g. ?access_token=…, ?sig=…, ?code=….

Combine the checkbox with terms to scope a hunt, e.g. query refresh with Credential traffic on to find every token-refresh call.

[!WARNING] Credential search exists for authorized testing of systems you own or are contracted to test. Hits expose where live secrets travel; handle them under your engagement’s data-handling rules. Sensitive values are masked in analysis views by default — see /docs/en/security/.

Each result row shows:

  • The method badge and authority + path (a WebSocket badge appears on upgrade requests).
  • The capture (session) name the hit came from.
  • Matched-field chips (url, status, request headers, request body, response headers, response body).
  • The response content type and a color-coded status badge.

Click a row to open that exact request in the workspace. The result list scrolls independently of the filter toolbar, so you can refine terms without losing your place.

Behavior on large captures

Search executes entirely in the frontend over the in-memory exchange list — there is no server query round-trip per keystroke.

  • Hit cap: results stop at 500 exchanges. When the cap is reached, a first 500 shown badge appears; narrow the query or add filters to reach deeper matches.
  • Responsive typing: the query and host inputs are deferred (useDeferredValue), so the UI stays responsive while a large result set recomputes, and results are memoized between keystrokes.
  • Linear scan: every enabled exchange is checked in order, so cost scales with the total exchange count across enabled captures. On very large imports, use the method, status, and host filters to cut the working set before typing broad terms.

[!TIP] If a term should be in the body but you get no hits, confirm the body decoded as text: opaque or binary bodies are replaced with a placeholder and are not searchable.

Traffic Jam documentation. Built with Hugo.