Ingress Events

Every event that arrives at one of your endpoints is stored as an ingress event. CatchHook supports two event types:

• Webhook requests — HTTP requests captured from webhook endpoints, storing the full method, path, headers, body, query parameters, source IP, and timing information.
• Email events — inbound emails captured from email endpoints, storing the sender, recipients, subject, text/HTML bodies, headers, attachments metadata, and email authentication results.

Both types share the same lifecycle features: viewing, searching, forwarding, replaying, exporting, and alerting.

Viewing events

Events appear in two places:

• Endpoint page — the "Recent Activity" section shows the last 5 events in an accordion view with inline delivery events (forwards, tunnels, replays). New events stream in automatically via Turbo.
• Requests page in the sidebar — shows all events across your account with full search and filtering.

The global requests table handles mixed event types. Webhook events show HTTP method and path; email events show the subject line and sender.

Webhook event detail page

Click any webhook event to open the full forensic detail view. The page uses collapsible sections for a dense-but-readable layout. You'll see:

Email event detail page

Click any email event to open a tabbed detail view with four panels:

The detail page also shows:

• From / To / Subject — email envelope fields
• Email authentication — SPF, DKIM, DMARC, spam, and virus verdicts from AWS SES
• Detected provider — the originating email service (Gmail, SendGrid, etc.)
• Attachments — metadata for any email attachments (filename, content type, size)
• Message ID — the email's Message-ID header

Searching and filtering

Use the search bar at the top of the events list to find events by content. The search covers:

• Request body / email text body (full-text search)
• Path (webhook events)
• HTTP method (webhook events)
• Content type
• Source IP address
• Email to address (email events)

Additional filters are available via dropdowns:

• Status — filter by response code range (2xx, 3xx, 4xx, 5xx) (webhook events)
• Method — filter by HTTP method (webhook events)
• Date range — filter by received date
• Provider — filter by detected webhook source (GitHub, Stripe, Shopify, Slack, Twilio)
• Event type — filter by provider event type (e.g., push, invoice.paid)
• Source type — filter by webhook or email
• Sender — filter by email sender address (email events)
• Subject — filter by email subject (email events)

Results are paginated at 25 per page.

Starring events

Star important events to bookmark them for quick access. Click the star icon on any event in the list or detail view to toggle it.

• Starred events are marked with a yellow star icon.
• Use the Starred filter button (above the event list) to show only starred events. Click it again to clear the filter.
• Stars persist across sessions and are visible to all team members with access to the endpoint.
• Starring is available on permanent endpoints for signed-in users. Temporary endpoints do not support starring.

Tagging events

Tags let you categorize events with workspace-scoped labels for organization and quick identification.

Adding and removing tags

• Click the + icon on any event row or the detail page to open the tag dropdown.
• Select a tag to apply it. Click the x on a tag chip to remove it.
• Tags are workspace-scoped — the same tag vocabulary is shared across all endpoints in a workspace.
• Each workspace comes with system-defined preset tags: test, noise, and investigate.
• Create custom tags from the workspace management page (name + color).

Tag behavior

• Tags are purely organizational — they do not affect health metrics, alerts, or statistics.
• Tags are visible to all team members with access to the endpoint.
• Events can have multiple tags simultaneously.

Ignoring and resolving events

Mark events as ignored or resolved to exclude them from health calculations, alert evaluation, and endpoint statistics. This is useful for removing noise (accidental requests, test traffic, misconfigured webhooks) without deleting the event.

How to ignore or resolve

• Click the eye-off icon on any event row to open the ignore dropdown.
• Choose a reason: Ignore (noise), Ignore (mistake), Ignore (test), or Resolve.
• To undo, click the x on the ignore badge.
• On the event detail page, the ignore/resolve button appears in the header actions area.

Bulk resolve

On the endpoint health panel, click Resolve all next to the recent failures list to mark all recent failure events as resolved in one action. This clears the failure state without deleting any data.

What "ignored" means

Ignored vs. resolved

Both use the same underlying mechanism (excluded from health), but carry different semantic intent:

Permissions

Ignoring and tagging require update access to the endpoint (the same permission level as forwarding or replaying).

Exporting events

Export the current filtered set of events as JSON or CSV:

1. Apply any search/filters to narrow the results.
2. Click the Export dropdown in the top-right corner.
3. Choose Export as JSON or Export as CSV.

The export includes: event ID, endpoint name, type (webhook/email), method (webhook), path (webhook), status (webhook), content type, source IP, timestamp, headers, and body. Email events additionally include from, to, subject, text body, and authentication results.

Exports are limited to 5,000 events per download. For larger datasets, apply date range filters to export in batches.

Requires an active subscription (Pro or Business).

Event timeline

Each ingress event includes a timeline that tracks every step in its lifecycle. The timeline appears in the event detail view and shows:

Each entry shows the timestamp, duration, and time delta from the previous event. Error events (failed forwards, bad signatures) are highlighted in red for quick identification.

The timeline helps debug delivery issues by showing exactly what happened and when — useful for identifying slow forwards, failed signatures, or missed tunnel deliveries.

The detail page also includes:

• Diagnostic context — a summary card with content type, IP address, path (webhook) or sender (email), user agent, provider context, signature status (webhook), and delivery summary.
• Actions section — Replay and Compare displayed side-by-side on larger screens for quick access.
• Request body (webhook) / Email content (email) — collapsible, expanded by default, with JSON viewer, syntax highlighting, and download option.
• Response sent (webhook) — collapsible section showing the exact HTTP response returned to the sender (see below).
• AI Insights — collapsible section at the bottom for AI-powered payload summaries and handler code generation (Pro and Business plans).

Response capture (webhook only)

Every webhook request records the HTTP response that CatchHook returned to the sender. This lets you verify exactly what the webhook provider received, even if the endpoint's response configuration has changed since the request arrived.

The Response Sent section on the webhook detail page shows:

For head-only responses (no body), the section shows "No response body (head-only response)."

Response capture data is also visible in the request accordion list as a small status badge, and is included in the API response for individual request detail (GET /api/v1/endpoints/:id/requests/:id).

Not applicable to email events — email delivery responses are managed by AWS SES at the transport level.

Replaying an event

You can resend any stored event to a URL of your choice.

Webhook replay

CatchHook supports two replay modes for webhook events:

Exact replay

1. Open a webhook event and click Replay.
2. Enter the destination URL.
3. CatchHook preserves the original method, headers, body, and signature by default, then shows you the response status and timing.

This is useful for re-delivering a webhook that your server missed or for testing against a staging environment.

Modify & Replay

With a payment method on file, you can modify webhook events before replaying:

1. Open an event and click Replay, then switch to the Modify tab.
2. Edit the body, headers, and query parameters as needed.
3. Choose an Identity mode (Original or the provider-aware regeneration option for JSON payloads) and Signature mode (Preserve original, Strip, or Re-sign).
4. Click Replay to send the modified request.

Modifications you can make:

• Body — Edit the raw body directly. JSON bodies are validated before sending. Binary bodies cannot be edited.
• Headers — Change header values, remove existing headers, or add new ones. Restricted headers (Host, Content-Length, hop-by-hop, and X-Catchhook-* headers) cannot be overridden.
• Query parameters — Add, change, or remove query string parameters on the target URL.
• Identity mode — Generic JSON payloads receive unique identity suffixes. Provider implementations can own this behavior: Shopify's New delivery ID changes only X-Shopify-Webhook-Id, preserving X-Shopify-Event-Id and commerce resource IDs.
• Signature mode — Preserve the captured signature for an unchanged delivery, strip provider signature headers, or re-sign with the matching active provider configuration. Re-signing requires a supported signature configuration on the endpoint (not available for Twilio).

CatchHook shows provider-aware warnings when modifications may cause issues — for example, when editing a Stripe webhook body without re-signing.

For Shopify HTTPS deliveries, CatchHook surfaces the topic, shop domain, API version, delivery ID, merchant event ID, and privacy-safe resource context. Configure the Shopify app client secret on the endpoint to verify X-Shopify-Hmac-Sha256 against the raw body.

Email replay

Email events are replayed as a normalized JSON POST to your target URL. The replay modal starts in Modify mode, showing the normalized JSON body so you can review or edit the payload before sending.

The normalized JSON format includes: event, id, endpoint_id, received_at, from, to, subject, text, html, headers, attachments, message_id, provider, and authentication.

Replay history records whether the event was sent as-is or modified, along with the outbound snapshot (URL, method, headers, body) for debugging.

Saving a Replay Case

When an event should become a repeatable regression check, choose Save as Replay Case from the request or replay workflow. A Replay Case stores an encrypted source snapshot, one fixed target, replay options, and required deterministic assertions. It remains runnable after the original event expires, and every rerun creates immutable evidence.

See Replay Cases for assertion semantics, run statuses, lifecycle behavior, permissions, and plan limits.

Comparing events

Compare two events side by side to see exactly what changed. This is useful for understanding payload drift, debugging replay differences, and tracking provider schema changes.

How to compare

1. Open any event detail page.
2. In the Compare section, click Compare with Previous to diff against the chronologically preceding event on the same endpoint.
3. Or click Select request to choose a specific event from the dropdown (shows the 10 most recent events on the same endpoint).

What the comparison shows

The compare page breaks down differences across multiple dimensions:

Raw diff view

For body and header sections, click View raw diff to toggle a traditional side-by-side text diff powered by @pierre/diffs. The raw diff view is automatically disabled for binary payloads, encrypted endpoints, or bodies over 1 MB.

The rendered raw diff content is truncated at 256 KB per side to keep the browser responsive. Payloads between 256 KB and 1 MB will show a truncated diff with a notice; payloads over 1 MB disable the raw diff entirely.

Sensitive header values are always masked in the raw diff. For JSON bodies, sensitive keys (like password, api_key, access_token, credit_card) are replaced with [REDACTED]. Non-JSON bodies (e.g., text/plain, application/xml) are shown as-is after truncation — key-based redaction only applies to JSON-structured content.

Safety and access control

• Requires a payment method on file for authenticated users (Pro or Business plan with active payment method). Anonymous users on temporary endpoints can compare freely.
• Comparisons are scoped to the same endpoint — you cannot compare events across different endpoints.
• Cross-account access is prevented. Authenticated users can only compare events they have policy access to. Anonymous users can only compare within their temporary session.
• The compare feature works on both top-level (/requests/:id/compare) and nested (/endpoints/:endpoint_id/requests/:id/compare) routes.

Large and binary payloads

CatchHook handles payloads of all sizes and formats:

• Large payloads (over 256 KB) are shown in a truncated preview with an option to expand or download the full body.
• Binary payloads (protobuf, msgpack, gRPC, etc.) are stored safely and displayed as a hex dump preview.
• Payloads over 10 MB are rejected with a 413 Payload Too Large response.

A "Large payload" badge appears in the event list for oversized events.

Downloading the body

Click Download body on any event to save the raw payload as a file. Helpful for large payloads or binary-encoded content.

Deleting events

• Single event — click the delete icon on any event.
• All events for an endpoint — use the Delete all action on the endpoint's events tab.

Deleted events cannot be recovered.

Data retention

Events older than your plan's retention window are automatically purged.