Published December 15, 2025 · Last updated October 1, 2026

Which Unified API Platforms Support Virtual Webhooks vs Sync-Based Notifications?

December 15, 2025

Every unified API vendor says it supports webhooks. The label doesn't tell you much. What matters is what happens when an integration has no webhooks of its own: does the vendor detect changes at the source and deliver them to you, or does it sync data into its own store and tell you something changed?

The short answer: vendors use three models, native webhooks, virtual webhooks and sync-based notifications, and several use more than one. "Virtual webhooks" isn't unique to any one vendor anymore. The differences that matter show up in three questions: how often the vendor checks for changes, what the event actually carries, and what you pay for a check that finds nothing.

What are the three ways unified APIs deliver change events?

Native webhooks. The integration sends the event itself. The vendor registers a subscription with the integration and forwards events as the integration sends them. This is the fastest path when it exists, but many SaaS APIs offer webhooks only for some objects, and some offer none at all.

Virtual webhooks. Where an integration has no webhooks, the vendor checks the source API on an interval, detects what changed, and delivers events through the same webhook interface you use for native ones. Done well, this happens without keeping a copy of your customers' data: the vendor holds a read position between checks, not the records.

Sync-based notifications. The vendor syncs records into its own database on a schedule, then sends a notification when the sync finishes or when its stored copy changes. Your application usually calls the vendor's API afterwards to get the records.

The first two deliver changes from the source. The third delivers news that the vendor's copy changed.

Is "virtual webhooks" unique to one vendor?

No. Apideck uses the term for its own interval-based mechanism and states that it doesn't persist resource data (Apideck webhooks guide, read 20 Sep 2026). Knit's pricing page lists "Virtual webhooks" as a feature on every plan (Knit pricing, read 30 Sep 2026).

So the useful question isn't whether a vendor has virtual webhooks. It's how they behave.

What three questions separate the vendors?

1. How often does it check? An interval sets your worst-case delay. A one-minute check suits alerts and user-facing features; a daily one doesn't.

2. What does the event carry? Some events include the changed record, so your handler can act on it straight away. Others carry an ID, a link or a list of changed object types, and your application has to call the API to find out what changed. That follow-up read brings back pagination, retries and deduplication, which is the work you were trying to hand off.

3. What does a check that finds nothing cost? If every check is billable, a short interval gets expensive on quiet accounts, and you end up choosing a longer interval to control cost. If empty checks are free, a short interval costs little when nothing changes.

How do the major unified API vendors compare?

Vendor	Change-event models	Documented check or sync interval	What the event carries	Follow-up read	Customer data stored
Unified.to	Native and virtual	Virtual: as often as every minute on paid plans, every 60 minutes on free (as of September 2026)	The changed records	Not needed	No records at rest
Apideck	Native and virtual	Virtual: "typically every 24 hours," adjustable by plan; no minimum published	Entity ID and a URL to retrieve it	Yes	States no resource data is persisted
Merge	Sync-based, with native webhooks feeding its store	Daily on Free and Launch plans; faster settings not named	Changed Data events carry the record; sync events carry status only	For sync events	Yes, until the customer deletes it
Kombo	Sync-based, with native webhooks feeding its store	Plan-dependent; no default in its docs	The names of the data models that changed	Yes	Yes
Paragon	Sync-based (Managed Sync); Integration Triggers	Customer-set, one-minute minimum	Identifiers only (Managed Sync)	Yes	Yes (Managed Sync)
Truto	Native forwarding for change events	No interval-based change detection; a separate scheduled pipeline runs at five minutes minimum	The changed record	Not documented	Not by default; an opt-in synced store exists
StackOne	Native	Not documented for events	Identifiers for account events; the integration's own shape for integration events	Not documented	Not on the event path; its separate sync product keeps records for up to 30 days
Sources for each row are listed at the end of this post.

A few things stand out:

Apideck is the closest match to Unified.to's model, with native and virtual webhooks and no stored resource data. The differences are the interval, a documented 24 hours against one minute, and the payload: Apideck's data events carry an ID and a retrieval URL, not the record.
Merge and Kombo sync into their own stores, and their events come off that stored copy. Kombo's data-changed event names the models that changed and nothing else, so you fetch the changes afterwards.
Paragon offers a one-minute interval, but Managed Sync events carry no record data, so every event is followed by a read.
Truto delivers the record in the event, but only where the integration sends its own webhooks. It has no interval-based change detection.

How does Unified.to handle each model?

Unified.to supports native and virtual webhooks through one API and one payload format.

Native webhooks register with the integration, which sends events as they happen; Unified.to forwards them.
Virtual webhooks check the integration for changes on the interval you set, as often as every minute on paid plans and every 60 minutes on free, as of September 2026. Changes are detected with the source's timestamps and cursors, and nothing is stored between checks.
Every delivery carries the changed records, in the same format as the corresponding API endpoint, with a signature you verify using HMAC-SHA256.
Billing: checks that find no changes aren't billed. When changes are found, you're billed per page successfully delivered to your webhook URL. Failed delivery attempts and retriable read errors aren't billed, as of September 2026.
Retries: if your endpoint doesn't respond, delivery is retried three times immediately. A virtual webhook then keeps retrying with backoff for up to about two weeks, re-reading the same page from the integration rather than resending a stored payload. A native webhook is marked unhealthy after the three retries.
Deletes are delivered on native webhooks, and on virtual webhooks where the integration supports it. The integration's Feature Support tab in the dashboard shows which.

Details: How to create and configure webhooks, How to troubleshoot unhealthy webhooks.

Should you rely on webhooks alone?

Most vendors say no, and they say it in their own docs:

Merge recommends combining webhooks with polling and calling your sync functions every 24 hours (Merge syncing best practices, read 20 Sep 2026).
Kombo recommends a periodic full fetch alongside its webhook, on a seven-day schedule, to correct drift (Kombo fetching data, read 20 Sep 2026).
Apideck's own scaling guide recommends keeping a low-frequency full reconciliation running, because events can be missed (Apideck syncing accounting data at scale, read 20 Sep 2026).

Unified.to gives the same advice for the same reason: keep one low-frequency reconciliation read per object to catch anything a webhook missed, mainly deletions on integrations that don't report them. See Replacing Polling with Event-Driven Integrations.

When does each model make sense?

Native webhooks fit when the integration supports them for the objects you need and your product has to react as changes happen.

Virtual webhooks fit when the integration has no webhooks, or only partial ones, and you want the vendor to own change detection and delivery without holding your customers' data. Check the interval and the payload before you commit.

Sync-based notifications fit when you want a stored replica for reporting or batch access and timing matters less than having the copy. Be careful with them when latency shows up in your product, when you want to avoid a notify, read, reconcile loop, or when stored customer data affects your compliance review.

For the same decision inside your own application, between polling, native webhooks and virtual webhooks, see Polling vs Webhooks: When to Use One Over the Other.