Each gateway call creates a durable Trace and append-like TraceEvents: request.received, contract.validated, scenario.matched, response.sent, plus future idempotency/state/queue detail events. Payloads pass through secret redaction before persistence.
#Reading one
The console shows them per application, under Trazas: the listing is paged,
sorted and filtered on the server like every other one, and correlationId is
the column that matters — it is what a caller sends in X-Correlation-Id to tie
a trace here to a line in their own logs.
Opening one shows its moments in order, with the milliseconds between them and each payload behind a fold:
request.received +0 ms body · path · method · headers
application.resolved +2 ms provider · applicationId
contract.validated +3 ms operation
scenario.matched +3 ms scenario · source · outcome
response.sent +41 ms statusCode · resourceId · replayed
That sequence answers what a status code cannot: which tenant the credential
resolved to, whether the body satisfied the contract, which scenario matched and
whether it came from the application or from X-Emulator-Scenario.
Events are read through the application in the path, not by trace id alone. A
trace carries the request that made it, so resolving one by id would have been a
way past the tenant scope. A trace id from a tenant the caller cannot see is
trace_not_found, like any other invisible row.
Payloads are redacted at capture, before anything reaches the database:
authorization and card tokens are already [REDACTED] in storage, so this page
cannot leak what it never received.