Mutation Probes & Token Lifecycle

Both features live in the Collector workspace of the API view. Mutation probes actively replay altered requests to map what an anti-fraud system tolerates; token lifecycle passively reads your captures to work out the session economics. Only run probes against systems you are explicitly authorized to test — each probe sends live requests to the target.

[!WARNING] Mutation probes deliberately send tampered traffic (rotated cookies, forged device fields) to a production anti-fraud backend. That is active testing. Confirm you have authorization for the target before clicking Run probe.

Run a mutation probe

Open the Collector workspace → Probes tab. The panel takes one captured request plus a list of single-field mutations:

1. Pick the Probe target request from the session/request picker.
2. In the Mutations box, choose a location, type the field name and replacement value, then click Add. Repeat for each field you want to test.
3. Leave Pairwise pass checked (it shows the pair count, N×(N−1)/2) and click Run probe.

The probe replays a baseline (the request as captured), then one replay per single mutation, then one replay per pair. Execution is chunked under the backend’s 50-request batch cap, and the button shows live done/total progress.

How mutations are applied

Each mutation targets one location. Cookie and body mutations preserve everything else in the request:

[!NOTE] Pairwise is enabled by default only when there are 12 or fewer mutations, since the pair count grows quadratically. Uncheck it to run singles only.

Stacked-rejection detection

The point of the pairwise pass is the case the singles pass cannot see: two mutations that are each accepted alone but rejected in combination. A pair is flagged a stacked rejection when both of its single mutations were accepted and the combined replay was not. Stacked rows are highlighted in the report and trigger a warning toast. The summary line reads, for example, 3/4 mutations accepted alone; 2 pairs rejected when stacked.

Read the probe report

The results table lists baseline, singles, then pairs with their HTTP status and verdict. A replay is accepted when the server returned no rejection class and a 2xx/3xx status; redirects count as accepted because replay never follows them. Otherwise the verdict shows the rejection class:

A mutation that flips the baseline from accepted to antifraud-reject identifies a field the anti-fraud logic binds to. See /docs/en/replay/workbench/ for the full rejection vocabulary and /docs/en/replay/fingerprints/ for controlling the TLS fingerprint on replay.

Device-identity consistency rules

When you run a conformance diff (Collector → Conformance tab → Run conformance diff), the same pass runs device-identity rules over the subject capture’s decoded telemetry bodies and request headers. They catch an internally inconsistent device fingerprint before the server does. Violations show as a ruleId badge plus message (up to 10 listed):

The fields that must move together are therefore SDK↔release, pixel dims↔density, platform↔hardware, UA build tag↔PhoneID, and device-id↔model. Mutating one without the others is exactly what these rules — and the server — flag.

Track token lifecycle

The conformance pass also builds a token-lifecycle report for the subject session. It is passive: it reads Set-Cookie response headers and token-shaped JSON response fields as mint events (JSON fields are named json:<leaf>, so data.cs.gssc becomes json:gssc), request cookies as consume events, and notes when a minted value later travels in a request URI. Each distinct value is tracked by an 8-char-plus-length fingerprint, and every response it appears in is recorded as an outcome.

A value went stale when it succeeded (status < 400, no rejection) and was later rejected. From that, each token gets a staleness class:

For stale tokens the report computes a freshness window (min/median/max milliseconds between last success and first rejection). The panel lists the top 10 tokens with name, staleness badge, and minted N× · consumed N× · in URIs N×.

Read the session-model hints

Above the token list, the report emits plain-language hints that map directly onto how a collector should treat each token:

• Bootstrap once, reuse: minted tokens that never went stale — fetch once and reuse the tuple.
• Derive or refresh per request: single-use or freshness-bound tokens — recompute or re-mint each send (see /docs/en/replay/variables/ for computed fields and /docs/en/collector/signatures/ for recovering the derivation).
• Minted outside the capture: consumed but never minted in the recording — an external bootstrap step is required before replay.