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.
Open global search
- Open the API lab view (see /docs/en/api-re/).
- Select the Search tab (the second tab, after Catalog).
- 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 label | Contents searched |
|---|---|
url | Method, authority (host), path, query string, and the full URL |
status | Numeric status code and status text (e.g. 404 Not Found) |
request headers | Every request header line, in captured order |
request body | The decoded request body text |
response headers | Every response header line |
response body | The 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 500finds an exchange whose URL containsordersand whose status is500. - 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%2fto/and%3ato:, 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.
| Control | Values | Behavior |
|---|---|---|
| Method | GET, POST, PUT, PATCH, DELETE, OPTIONS | Exact method match (case-insensitive) |
| Status | 2xx, 3xx, 4xx, 5xx | Matches the status class; exchanges with no recorded status are excluded |
| Host contains… | Free text | Case-insensitive substring match on the authority (host) |
| Credential traffic | Checkbox | Keeps 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, orapi_key(case-insensitive). - A query parameter name ends in
token,secret,key, orsig, or is exactlycode— 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/.
Navigate from a hit to the request
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 shownbadge 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.