AI agent? Read this page as Markdown at /concepts/virtual_webhooks.md — append .md to any docs URL, or start from /llms.txt.
Understanding virtual webhooks
This guide explains what virtual webhooks are, how they differ from native webhooks, and when you would want to use a virtual webhook.
What are virtual webhooks?
Virtual webhooks are Unified.to's solution for providing webhook functionality even when an integration doesn't natively support it. They detect changes in your customers' connected applications on a schedule you set, for new or updated records, and for deleted records where the integration supports it, and deliver those changes as events to your webhook URL.
While native webhooks are great when they're available, many software vendors either don't support webhooks or have limitations with their webhook implementations. Virtual webhooks bridge this gap by providing a consistent webhook experience across the integrations that support them.
How virtual webhooks work
Virtual webhooks work by:
- Monitoring your connections for updates to specific objects (e.g., CRM deals, ATS jobs, etc) at regular intervals (polling)
- Detecting when data has changed or new data has come in since the last check
- Sending updates to your webhook URL only when changes are found
- Managing rate limits automatically
The key difference from native webhooks is that virtual webhooks use polling behind the scenes, but this complexity is managed by us so that you, the developer, don’t have to worry about it. You interact with virtual webhooks as you would with native webhooks.
Virtual vs native webhooks comparison
| Virtual Webhooks | Native Webhooks | |
|---|---|---|
| Implementation | Detects changes on your interval and delivers events | Forwards events as the integration sends them |
| Setup | Configured entirely through Unified.to | May require configuration in the integration's own settings |
| Cost Structure | No charge for checks that find nothing. One API call per page of changes successfully delivered to your webhook URL. You set the interval. | One API call per successful delivery to your webhook URL |
| Event Types | Created and updated; deleted where the integration supports it (see Feature Support) | Supports created, updated, and deleted events if the integration supports them |
| Retry Logic | 3 immediate delivery retries, then progressive backoff for up to about two weeks; reads from the integration are retried with the same backoff | 3 immediate delivery retries; no extended backoff. Further delivery depends on the integration sending the event again |
| Health Monitoring | Built-in is_healthy tracking | Built-in is_healthy tracking |
When to use virtual webhooks
Virtual webhooks are ideal for:
- Tasks where 1+ minute delays are acceptable and you don’t need the data immediately
- When you want greater control over costs by setting the frequency the integration is polled
- Integrations that don't offer native webhook support
When an integration offers both virtual and native webhooks, consider native webhooks when:
- You need immediate updates as soon as they arrive
How to identify webhook support
You can check what type of webhook support an integration offers:
- Navigate to the integration's page in the Unified.to dashboard
- Click on Feature Support
- Look under the Webhooks section:
- Each event shows which types support it, for example "native & virtual created event" or "native deleted event"
In this example, the integration supports virtual updated and virtual created events.
Creating and configuring virtual webhooks
You create and configure virtual webhooks the same as you would with any other webhook, with the exception of also being able to set an interval, and filters where the integration supports them. The minimum interval is 1 minute. To see how to do that, refer to: How to create and configure webhooks