Endpoint Actions

Actions let you automate what happens when a webhook or email arrives at an endpoint. Each action contains one or more steps that execute in order, with optional trigger conditions to control when they run.

Requires Pro, Team, or Business plan.

Creating an action

1. Open an endpoint and expand the Actions panel.
2. Click New Action.
3. Give it a name and optionally add trigger conditions.
4. Add one or more steps (forward, notify, tag, ignore).
5. Save.

Actions run automatically on every matching request. You can also rerun them manually against historical requests.

Step types

Forward

Routes the incoming webhook or email to your server.

Forward steps require an active paid subscription. Trials are not eligible, even when a payment method is attached. If paid access lapses, existing Forward steps remain saved but cannot run or be reconfigured until billing is active again.

• URL (required) — the destination URL (e.g., https://api.example.com/webhooks)
• Timeout — how long to wait for a response (1–300 seconds, default 30)
• Retry Count — how many times to retry on failure (0–5)
• Append Original Path — add the original request path to the forward URL
• Append Original Query — add the original query string to the forward URL

Webhook events are forwarded with the original HTTP method (including GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), headers, and body. Email events are forwarded as a normalized JSON POST. Response bodies are capped at 1 MB and truncated to 500 characters in traces.

Forward steps send events to publicly reachable HTTP(S) destinations. For localhost development, use the CatchHook CLI tunnel to stream events to your local server. See Security & Privacy for outbound request safeguards.

Notify

Sends a notification through any configured notification channel.

• Channel (required) — select from your configured notification channels (Slack, email, Discord, PagerDuty, Teams, webhook)
• Message Template — customize the notification message with variables:
  • {{endpoint_name}} — the endpoint name
  • {{endpoint_id}} — the endpoint prefix ID
  • {{request_id}} — the request prefix ID
  • {{event_type}} — the detected provider event type
  • {{provider}} — the detected webhook provider

Notifications route through the standard delivery pipeline — disabled or circuit-broken channels are skipped, delivery counts are tracked against your plan limits, and failures trigger the same automatic channel management as alert notifications. Notify steps default to "continue" on failure; set a per-step failure policy of "stop" to override.

Tag

Automatically applies a workspace tag to the incoming request.

• Tag (required) — select from tags configured in your workspace

Tags are applied idempotently — if the request already has the tag, it won't be duplicated.

Ignore / Resolve

Marks the request as ignored with a reason.

• Reason — noise, mistake, resolved, or test (default: noise)

Ignored requests are hidden from the default request list and excluded from health metrics.

Trigger conditions

Conditions control when an action runs. All conditions must match (AND logic). Leave conditions empty to run on every request.

Available fields:

• Provider — the detected webhook provider (e.g., stripe, github)
• Event Type — the provider event type (e.g., checkout.session.completed, push)
• Signature Status — verified, failed, or unchecked
• HTTP Method — GET, POST, PUT, etc.
• Request Path — the request path
• Content Type — the content type header
• Sender (From) — sender address (email endpoints)
• Email Subject — email subject line (email endpoints)
• Has Tag — check for existing tags on the request

Operators: equals, not_equals, contains, not_contains, matches (regex), exists, not_exists

Limits: Up to 10 conditions per action. Condition values are limited to 500 characters. Regex evaluation has a 1-second per-pattern timeout and a 5-second aggregate budget across all conditions.

Failure policies

Control what happens when a step fails:

• Continue (default) — skip the failed step and keep running
• Stop — halt execution immediately, mark remaining steps as stopped

Set a default policy on the action, then override per-step if needed. Notify steps default to "continue" but can be explicitly overridden to "stop" per-step.

Execution traces

Every action run is recorded with a step-by-step execution trace visible in the request detail view. Traces show:

• Overall run status (completed, failed, stopped)
• Per-step status with timing
• Output from each step (HTTP status codes, delivery results, errors)
• Trigger condition evaluation results

Rerun support

Made a configuration change? Rerun any action against a historical request:

1. Open a request detail view
2. Find the action in the execution trace
3. Click Rerun

Reruns are enqueued as background jobs and create a new action run with the current configuration applied to the historical request data. Old runs are preserved for comparison. Deleting an action preserves all execution history — runs continue to appear in traces with their recorded snapshots.

Plan limits

API

Actions are fully manageable through the REST API:

GET    /api/v1/endpoints/:id/actions
POST   /api/v1/endpoints/:id/actions
GET    /api/v1/endpoints/:id/actions/:action_id
PATCH  /api/v1/endpoints/:id/actions/:action_id
DELETE /api/v1/endpoints/:id/actions/:action_id

The single-action response includes its 10 most recent execution traces. The legacy
/endpoint_actions route remains available as an alias.

MCP tools

Four MCP tools are available for AI editors:

• list_actions — list all actions on an endpoint
• create_action — create a new action with steps and conditions
• delete_action — delete an action
• get_action_runs — inspect execution traces for debugging