What Are Virtual Webhooks? How They Differ From Sync-Based Webhooks

A virtual webhook is a webhook that an integration layer such as Unified.to provides for an integration whose API doesn't send its own: it detects changes by reading the source API on a fixed interval and delivers the changed records, as events, to your webhook URL. A sync-based webhook, or sync-based notification, is different in kind: the platform copies data into its own storage on a schedule and notifies you when the sync finishes, and your application follows with an API call to fetch what changed. On Unified.to, as of September 2026, [virtual webhooks](/blog/what_are_virtual_webhooks_how_they_differ_from_sync_based_webhooks) are available on supported integrations and objects, the interval can be as short as one minute on paid plans, Unified.to stores no customer records at rest, and the event carries the changed records where supported.

Each virtual webhook check compares what comes back against the last successfully delivered position, using timestamps and cursors, and delivers only the records that changed. A polling job does the same reading, but inside your application, with your team maintaining the scheduler, cursors and retries.

For how individual unified API platforms implement these models, see Which Unified API Platforms Support Virtual Webhooks vs Sync-Based Notifications. For when to poll and when to use webhooks at all, see Polling vs Webhooks: When to Use One Over the Other.

What does "change detection" mean for an integration?

Change detection is the mechanism by which a system learns that a record in a third-party API was created, updated or deleted, and it decides latency and complexity more than whether a webhook endpoint exists. Teams comparing webhooks with polling are choosing how change detection works underneath, and "webhook support" is used to describe three different mechanisms.

How do native webhooks detect changes?

With a native webhook, the source API does the detection: it registers the change internally and sends an event to the subscribed endpoint, so nothing has to be checked from outside (see webhook vs API for the basics). Payments, e-commerce orders and Git events are the common cases.

The limit is coverage. Many SaaS APIs offer no webhooks, and many that do offer them only for some objects. Retry behaviour, ordering and payload shape also vary by integration. On Unified.to, a native webhook is registered with the integration and forwarded to you as it arrives; where the integration's event carries only an identifier, Unified.to fetches the full record before delivering it.

How do unified APIs handle vendors that lack native webhooks?

Unified.to forwards a vendor's native events where the vendor sends them and, where it doesn't, provides virtual webhooks on supported integrations and objects, which detect changes by reading the source API on an interval and deliver events carrying the changed records to your webhook URL. As of September 2026, the mechanism is:

1. Read on the interval. Unified.to calls the integration's list endpoint for the subscribed object on the interval you set: as often as every 1 minute on paid plans, every 60 minutes on the free trial. These calls count against the integration's rate limit, and Unified.to backs off and honours the integration's retry-after guidance when it's rate-limited.
2. Detect what changed. Detection uses timestamps and cursors, reading what changed since the last successful delivery. Deleted records are detected where the integration supports it, which is shown on the integration's Feature Support tab in the dashboard.
3. Deliver the records. Changes are delivered as a signed POST containing the changed records in the API's format, one delivery per page. Unified.to stores no customer records at rest; only the read position is kept between checks.
4. Advance only on success. The read position moves forward after your endpoint acknowledges the delivery. If it doesn't, the retry re-reads the same page from the integration rather than resending a stored payload, with up to three immediate attempts one second apart, then delayed retries that back off progressively for up to about two weeks. If retries are exhausted, the webhook is marked unhealthy and scheduling stops; to fix the cause and recreate it, see how to troubleshoot unhealthy webhooks. For how reads and deliveries recover independently before that point, see how virtual webhook retries and recovery work.

Your application subscribes once and receives events; the scheduled reads happen inside Unified.to rather than in your codebase. For the full mechanics, see Understanding virtual webhooks in the docs.

How much delay does a virtual webhook add?

A virtual webhook's delay is set by its check interval: average delay is half the interval, worst case the full interval. That figure varies more between platforms than the shared "virtual webhooks" label suggests. Unified.to's minimum is 1 minute on paid plans. As of 8 October 2026, Apideck's help centre describes its virtual webhooks as checking "typically every 24 hours," adjustable by pricing plan, re-listing all items per resource on each cycle.

How do sync-based notification systems work?

A sync-based platform runs a scheduled sync of your customer's data into its own storage, and sends a webhook when the sync completes or when it detects a difference in the stored copy; the webhook often tells you something changed, not what, and your application fetches the records separately. These are notifications tied to a batch process, not change detection at the source. You react after the sync completes, not when the change occurred.

The documentation of platforms using this model says so directly. Kombo's documentation says its data-changed webhook arrives "with an array of models that have changed in our database," not the records, so your application then fetches the changes from Kombo's API; outside the integrations where Kombo subscribes to upstream webhooks, changes surface after the scheduled sync, which defaults to three hours (Kombo as of 8 October 2026). Merge's sync notification webhook carries a sync status rather than records, Merge recommends "a combination of webhooks and polling," and its implementation guide tells you to keep calling your sync functions every 24 hours (Merge as of 1 October 2026). Rutter's webhook guide computes webhooks "each time an Incremental Sync runs," on a default 60-minute schedule, and sends real-time webhooks on QuickBooks Online, Xero, Stripe and Sage Intacct (Rutter as of 8 October 2026).

How do the three models compare in production?

Native webhooks, virtual webhooks and sync-based notifications look similar at a glance and behave differently in production on four things: latency, what the event contains, where the scheduled reading lives, and whether data is stored.

What's the key difference: data or signal?

The key difference between virtual and sync-based webhooks is what the event carries: a virtual webhook is generated from a change detected at the source and delivers the changed records, while a sync-based webhook is generated from a change in a stored copy and usually delivers only a signal that something changed. That decides how much retrieval code you still own. If every event requires another API call, your system still needs retrieval logic, pagination and retries after each one. On Unified.to, the data array carries the records in the same format the corresponding API endpoint returns, with the same fields options, including raw and custom fields.

Where does the polling logic live?

Polling logic lives in your application with a polling job, in the integration layer with virtual webhooks, and in the platform's batch jobs against its own stored copy with sync-based notifications. Only a native webhook needs no scheduled reading. The choice is whether that logic sits in your application or is handled once in the integration layer.

How do the models differ on data handling?

Sync-based platforms keep a stored copy of your customers' records and generate events from it; Unified.to reads from the source API when events are generated and stores no customer records at rest. That affects compliance scope, because a stored copy is data you have to account for; latency, because the copy is only as current as the last sync; and migration risk, because an application built on a platform's stored copy depends on that platform's schema and schedule.

What does this look like in your application?

With sync-based notifications, your application fetches, paginates, deduplicates and retries after each notification; with Unified.to virtual webhooks, it verifies, applies and acknowledges records the event already carries.

With sync-based notifications: receive the notification, call the platform's API for changed records, handle pagination, deduplicate, manage retries.

With Unified.to virtual webhooks: verify the sig256 signature, apply the records with an idempotent write (update only when the incoming updated_at is newer), acknowledge. Watch is_healthy and subscribe to WEBHOOK_UNHEALTHY on the notifications webhook, because an unhealthy webhook stops and doesn't resume until you recreate it.

The second list is shorter, but it isn't "receive, process." Signature verification and idempotency are yours in every model, and so is health monitoring. What you don't write is the scheduler, the cursor store, the pagination and the retry loop. That difference compounds across integrations and objects. To set one up, see How to create and configure webhooks.

When are virtual webhooks the right fit?

Virtual webhooks on Unified.to fit when an integration lacks native webhooks for the object you need and you'd rather not run polling or sync infrastructure. Specifically, when:

• the integration doesn't provide native webhooks, or provides them only for some objects, and Unified.to supports virtual webhooks for that integration and object
• your product depends on timely updates
• you want to avoid building and running polling infrastructure
• you want to avoid managing sync pipelines or stored replicas of your customers' data

Is "webhook support" enough to choose an integration platform?

No: "webhook support" isn't enough information to choose an integration platform; what matters is how changes are detected, when events are delivered, and whether the event carries usable data. Virtual webhooks move change detection and delivery into the integration layer and read from the source. Sync-based systems notify your application after data has been processed into a stored copy elsewhere. That distinction determines whether your application is built around events or around scheduled data retrieval.

Frequently asked questions

Do virtual webhook checks count against the integration's rate limit? Yes. Each check calls the integration's API, and Unified.to backs off automatically when rate-limited. What they remove is the request volume from your infrastructure, and Unified.to doesn't bill for checks that find nothing.

If a platform stores my customers' data, isn't that faster? Reads against a stored copy are fast, but the copy is only as current as the last sync, and the sync cadence sets your latency. It also puts a copy of your customers' data in another vendor's environment, which is part of your compliance scope.

→ Start your 30-day free trial

→ Book a demo

Written by Mallory Greene.

About the author: Mallory Greene is Head of Marketing at Unified.to. She writes about integration infrastructure, unified APIs, and MCP for technical teams. Based in Toronto.