Skip to main content
This guide covers how to create, test, and update a webhook, attach it to a job or monitor, and troubleshoot delivery issues.

Before you begin

  • You have a CatchAll API key.
  • You have a publicly accessible HTTPS endpoint ready to receive POST requests, or use webhook.site for testing.

Create webhook

A webhook is created independently of any job or monitor. Once created, you attach it to one or more resources.
Response:
Save the webhook.id — you use it to attach the webhook to resources. For supported values of type, delivery_mode, and auth, see Create webhook API reference.

Read back the configured auth

Webhook responses include an auth object describing the authentication the webhook sends with each delivery. It is null when no authentication is configured. Secret values are always masked — the full token, API key, or password is never returned by the API:
Use auth.type to confirm which scheme is active, and non-secret fields such as header and username to verify the rest of the configuration. To rotate a credential, send a new auth object with Update webhook — you cannot recover the existing secret from the API.

Attach to a project at creation

Pass project_id to associate the webhook with a project in the same request:
cURL
This is equivalent to creating the webhook and then adding it to the project with resource_type: webhook. The project must belong to your organization — otherwise the call fails with 403, or 404 if no such project exists, and the webhook is not created. A webhook can be attached to more than one project, and deleting a project never deletes its webhooks.

Test before attaching

Before attaching a webhook to a live resource, verify that your endpoint is reachable and auth is configured correctly:
Response:
If success is false, check http_status_code and response_body to diagnose the issue before proceeding.

Attach webhook to job or monitor

You can attach a webhook to a job or monitor at creation time, or assign it to an existing resource afterward.

At creation time

Pass webhook_ids when submitting a job or creating a monitor:

After creation

Assign a webhook to an existing resource using the assignment endpoint:
Each resource supports up to 5 webhooks. Each webhook can be assigned to multiple resources.

Update webhook

Update any field on an existing webhook. Only supplied fields are changed:
To pause deliveries without deleting the webhook, set is_active to false.

Custom payload formatting

By default, webhooks send CatchAll’s standard payload. To tailor the request body to a downstream system — trim or rename fields, apply conditional logic, or emit a non-JSON format — create a webhook with type set to custom and supply a formatter_config. formatter_config takes two fields:
  • template — a Liquid template string rendered at dispatch time (maximum 10 KB). Reference delivery variables such as event and records_count.
  • content_type — the Content-Type of the rendered output. Defaults to application/json. Supported values: application/json, application/ld+json, text/html, text/plain, text/xml, application/xml, text/csv.
formatter_config is required when type is custom and ignored for other types. Update it later with PATCH /catchAll/webhooks/{webhook_id}.

Handle deliveries

Your endpoint must meet the following requirements and handle incoming requests reliably.

Endpoint requirements

Your endpoint must:
  1. Return a 2xx status code within 5 seconds.
  2. Be publicly accessible — localhost and private network addresses are not supported.
  3. Use HTTPS — HTTP endpoints are not accepted.
  4. Accept POST requests with a JSON body.

Return 200 immediately

Return 200 before processing to avoid timeouts. Process the payload asynchronously:

Debug deliveries

Use the delivery history endpoint to inspect past dispatch outcomes:
Each record shows the HTTP status code returned by your endpoint, the delivery outcome (SUCCESS or FAILED), and any error or warning messages. Each record’s resource_type is job, monitor, or monitor_group for a real delivery. Manual test deliveries are recorded with resource_type set to test, since they are not tied to any real resource — use this to tell your own test calls apart from production traffic. test is only ever returned in delivery history; you cannot assign a webhook to it.

Trigger delivery manually

To re-deliver results after a failed delivery — or to push a resource’s results on demand without waiting for the next job or monitor cycle — trigger a webhook manually. The webhook must already be assigned to the resource.
Pass an optional job_id query parameter to replay a specific past run. When omitted, the latest available results are delivered.

See also