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.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 anauth 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:
- Bearer
- API key
- Basic
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
Passproject_id to associate the webhook with a
project in the same request:
cURL
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: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
Passwebhook_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: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 withtype 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 aseventandrecords_count.content_type— theContent-Typeof the rendered output. Defaults toapplication/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:- Return a 2xx status code within 5 seconds.
- Be publicly accessible — localhost and private network addresses are not supported.
- Use HTTPS — HTTP endpoints are not accepted.
- Accept POST requests with a JSON body.
Return 200 immediately
Return200 before processing to avoid timeouts. Process the payload
asynchronously:
- Python
- TypeScript
- Java
Debug deliveries
Use the delivery history endpoint to inspect past dispatch outcomes: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.job_id query parameter to replay a specific past run. When
omitted, the latest available results are delivered.

