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, Transform, or HTTP Request).
5. Save.

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

Preview validates templates and transforms without sending an HTTP request. Secret references appear as placeholders.

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.

Transform (Business)

Builds a bounded JSON value for a later step without running user code. Transform operations run in order on a copy of the selected request, provider, email, or earlier-step value:

• select — choose a JSON Pointer path
• set — write a literal, context pointer, or bounded template value
• remove — remove a required path
• rename — move a value without overwriting an existing destination
• pick — construct an object from named paths
• wrap — place the value under one key

Transform is limited to 50 operations, 256 KiB, depth 32, and the action deadline. Its unredacted result is available only to later steps during the same run; traces contain a type and bounded summary.

HTTP Request (Business + active paid subscription)

Builds a new outbound HTTP request from the bounded context. URL, header values, and body templates use the strict action template language. HTTP Request supports GET, POST, PUT, PATCH, DELETE, and HEAD; GET and HEAD cannot have a body.

Requests use the same pinned-DNS SSRF protections as Forward, reject redirects and automatic retries, and enforce bounded URL/body/response sizes and timeouts. A 2xx response executes successfully. Other statuses fail the step, but a bounded response may be available to later steps when the action continues. HTTP Request may cause external side effects.

Action Secrets

Business workspaces can define encrypted values under Workspace → Action Secrets and reference them by name in HTTP templates, for example {{ secrets.fulfillment_api_token }}. Secret values are encrypted and write-only. CatchHook will not show this value again. Updating it replaces the current value. The editor and REST API expose names and metadata only; deletion is blocked while a step references a secret.

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.

Per-step conditions

Each step may have AND-only conditions using RFC 6901 JSON Pointer paths. Conditions can inspect the original request, provider, or email context and earlier enabled steps; they cannot inspect secrets, future steps, or arbitrary model state. A false condition is recorded as a redacted skipped step. An unavailable or invalid condition source fails the step and follows its failure policy.

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
• A redacted, size-bounded summary of each step outcome (HTTP status codes, delivery results, errors)
• Trigger condition evaluation results

Traces are evidence for debugging, not a durable output store. Sensitive values are masked, large values may be truncated, and raw intermediate values are not retained. HTTP response previews and Transform summaries are bounded and may not reproduce the full input or output.

Business metrics include a bounded Action Composition summary for a selected
time range: run/step totals by status and type, failures by error code,
expected condition_false skips, average step duration, and truncated trace
count. This summary contains no templates, URLs, payloads, or secret names;
condition skips are expected routing decisions and do not create endpoint
health incidents.

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 child run linked to the run you selected. They use the action configuration that is current when the rerun starts and apply it to the historical request data. Forward and Notify steps may cause external side effects. 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
POST   /api/v1/endpoints/:id/actions/:action_id/preview

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