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 simulate real-time updates by periodically checking for changes in your connected SaaS applications' data e.g. new records, update records, or deleted records. In other words, they use scheduled polling.
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 all supported integrations.
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 | Polling-based virtualization | Real-time push notifications |
| Setup | Configured entirely through Unified.to | May require additional configuration on other platforms |
| Cost Structure | One API call per interval when changes found - the interval can be set by you | One API call per event whenever they occur |
| Reliability | More controlled, depends on API availability | Depends on integration's webhook infrastructure |
| Event Types | Mainly supports created and updated events | Supports created, updated, and deleted events if the integration supports them |
| Retry Logic | Built-in for both reading and dispatching | Handled on a per-integration basis |
| Health Monitoring | Built-in connection health tracking with retry mechanism | Subject to your server’s availability and the integration’s retry mechanism |
When to use virtual webhooks
Virtual webhooks are ideal for:
- Integrations that don't offer native webhook support
- 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
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:
- Virtual webhooks are labeled with "virtual"
- Native webhooks are labeled with "native"
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 for the polling. To see how to do that, refer to: How to create and configure webhooks