Webhooks
BusinessWebhooks let you push real-time events from RadiusOS to external services - your own API, Zapier, Make, or any HTTP endpoint.
Overview
When something happens in RadiusOS (a contact is created, a stage changes, a task is completed), a webhook sends a JSON payload to a URL you specify. This lets you integrate RadiusOS with virtually any external tool without writing custom polling code.
Webhooks are on Business and Team. Free and Pro cannot configure webhook endpoints. If you are on Pro and want to connect RadiusOS to another app, Zapier is on every plan and covers most of the same ground.
Setting up a webhook
Go to Settings → Webhooks
Click + New Webhook to configure an endpoint.
Enter the endpoint URL
This is the URL that will receive POST requests when events fire. Must be HTTPS.
Select events
Choose which events trigger the webhook. Options include: contact.created, contact.updated, contact.deleted, contact.stage_changed, task.created, task.completed, email.sent, email.received.
Save and test
After saving, use the "Send Test" button to fire a sample payload to your endpoint and verify it's receiving data correctly.
Payload format
Webhooks send a JSON POST request with the following structure:
```json
{
"event": "contact.stage_changed",
"timestamp": "2025-01-15T10:30:00Z",
"workspace_id": "ws_...",
"data": {
"contact_id": "...",
"from_stage": "Lead",
"to_stage": "Qualified"
}
}
```
The `data` field varies by event type. All payloads include `event`, `timestamp`, and `workspace_id`.
When your endpoint is down
RadiusOS tries once immediately, then five more times over the next eight hours or so: on the next sweep (within 15 minutes), then 15 minutes later, 30 minutes, 2 hours and 6 hours. That window is sized for the thing it is actually for, which is your server being down for a deploy or an overnight outage.
Not every failure is retried, because not every failure improves with time. A 500 or a 503 is your end being broken, so we try again. A 429 is you asking us to slow down, so we do. A 404 or a 401 means the request itself is wrong and will still be wrong in six hours, so it stops immediately and shows up in the log for you to fix.
While that is going on, the delivery log shows the event as Retrying, with which attempt it is on and roughly when the next one is due. There is no Retry button on those rows on purpose: pressing one would send the payload immediately and then stop the automatic sequence, so an endpoint that came back ten minutes later would never get the event at all. Retrying means it is handling itself.
After the last try, the delivery is marked “Gave up” and stays in the log with a Retry button and a plain-English reason. Pressing it sends that exact payload once more, signed the same way. It does not restart the automatic sequence.
A deleted Zap answers with 410 Gone, and we take that at its word: the webhook turns itself off rather than posting to a dead URL every time something happens. Your own endpoints are never disabled automatically, whatever they return.
Retries are not the same as a guarantee. If your endpoint is down for longer than the window above, those events are not delivered, and RadiusOS is not a queue you can replay from. If you need to be certain you have everything, read from the API on a schedule rather than relying only on the push.