Replay Cases
Replay Cases turn a captured webhook or normalized email into a durable, endpoint-owned regression check. A case keeps one fixed target, encrypted source and replay configuration, and at least one deterministic assertion. It remains runnable after the original event expires.
When to use a Replay Case
Use a Replay Case when you want to:
- reproduce a provider event that exposed a handler bug;
- verify the same expected result after code or configuration changes;
- share a repeatable check with endpoint teammates;
- run the same case from the web UI, REST API, or MCP;
- retain bounded evidence for every attempt.
One-off replay remains available when you only need to resend or modify an event once.
Save a case
- Open a captured webhook or email event.
- Click Save as Replay Case from the request or replay workflow.
- Enter a case name and one fixed HTTP(S) target.
- Choose replay options.
- Add a status assertion, JSON-subset assertion, or both.
- Save the case.
Webhook cases preserve the captured method, headers, body, provider context, and supported identity/signature behavior. Email cases send the normalized email JSON payload as a POST.
The target belongs to the saved case version. A run cannot override it.
Assertions
Every runnable case needs at least one assertion:
- Status — allow one or more explicit HTTP status codes from 100–599, or require one status class such as
2xx. - JSON subset — require selected keys and type-strict values in a JSON response.
JSON object assertions require the expected keys and values but allow additional response keys. Array assertions use positional-prefix matching. Values are not coerced, so the number 1 does not match the string "1".
Replay Cases do not execute regex, JSONPath, expressions, or scripts.
Run evidence and statuses
Every run creates a new immutable record. Evidence includes bounded outbound request details, response details, assertion results, timings, and safe error information.
| Status | Meaning |
|---|---|
queued |
Waiting for a worker |
running |
Claimed and attempting one request |
passed |
Every configured assertion passed |
assertion_failed |
A response arrived but an assertion did not pass |
transport_failed |
No request could have been sent |
blocked |
Permission, billing, quota, target safety, or storage eligibility changed before sending |
unknown |
The request may have been sent, but the final outcome cannot be proven |
CatchHook never automatically retries a Replay Case after crossing the outbound-send boundary. Rerunning a case always creates a new run.
Response content is retained up to 1 MB. A status-only assertion can still pass when a larger response is truncated. A JSON assertion fails with response_too_large because the complete JSON value is unavailable.
Lifecycle and access
- Endpoint viewers can inspect cases and retained runs.
- Endpoint managers can create, edit, delete, and run cases.
- Deleting the source event does not delete the case.
- Deleting a case removes the reusable configuration but retains historical runs until account retention removes them.
- Editing replay configuration increments the case version. Name- or description-only edits do not.
- Lists expose metadata without decrypting case configuration. Detail views are bounded and redact restricted secrets.
Plan limits
| Plan | Replay Cases |
|---|---|
| Pro | 10 |
| Team | 50 |
| Business | 200 |
Cases are included during the selected plan trial. A downgrade preserves existing cases, but new saves are blocked while the account remains over its current limit.
REST API and MCP
The API reference documents endpoint-scoped case CRUD, runs, idempotency keys, optimistic locking, and retained-run inspection.
The MCP guide documents save_replay_case, list_replay_cases, get_replay_case, run_replay_case, and get_replay_case_run.