Which Unified API Platforms Support Virtual Webhooks vs Sync-Based Notifications?
·
Among unified API platforms, Unified.to, Apideck and Knit offer [virtual webhooks](/blog/what_are_virtual_webhooks_how_they_differ_from_sync_based_webhooks) that check the source API on an interval and deliver events; Merge, Kombo and Paragon's Managed Sync send sync-based notifications from their own stored copy; Truto and StackOne forward native webhooks; and several use more than one model (vendor docs read 20 September to 8 October 2026). For a team choosing a unified API, the differences that matter are how often the vendor checks for changes, what the event carries, and what a check that finds nothing costs. As of September 2026, Unified.to checks as often as every minute on paid plans, delivers the changed records where supported, and doesn't bill checks that find nothing.
What are the three ways unified APIs deliver change events?
Unified APIs deliver change events through native webhooks, virtual webhooks or sync-based notifications: the first two deliver changes from the source, and the third reports that the vendor's stored copy changed.
Native webhooks. The integration sends the event itself (see webhook vs API for the basics). 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. For the mechanism in detail, see What Are Virtual Webhooks? How They Differ From Sync-Based Webhooks.
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.
Is "virtual webhooks" unique to one vendor?
No: several vendors use the term "virtual webhooks." Apideck uses it for its own interval-based mechanism and states that it doesn't persist resource data (Apideck webhooks guide, read 8 Oct 2026). Knit's pricing page lists "Virtual webhooks" as a feature on every plan (Knit pricing, read 8 Oct 2026).
The useful question is how each vendor's virtual webhooks behave.
What three questions separate the vendors?
Three questions separate unified API vendors on change events: how often each checks for changes, what its events carry, and what a check that finds nothing costs.
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. Every check still calls the integration's API and counts against its rate limit.
How do the major unified API vendors compare?
The vendors differ most on check interval and on whether the event carries the changed record: Unified.to checks as often as every minute on paid plans and sends the records where supported, while Apideck's virtual webhooks check "typically every 24 hours" and send an entity ID and a URL to retrieve it (Apideck as of 8 October 2026).
| 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 the free trial (as of September 2026) | The changed records, where supported | Usually 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; source webhooks feed its store on Professional and Enterprise | Daily on Launch; on Professional and Enterprise, up to each integration's published Highest (5 minutes on OneDrive, as of October 2026) | 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 | 3-hour default per its docs; faster on Scale and Enterprise | The names of the data models that changed | Yes | Yes |
| Paragon | Sync-based (Managed Sync); ActionKit Triggers (beta) | Managed Sync: customer-set, one-minute minimum; Triggers: not published | Identifiers only (Managed Sync); the event payload (Triggers) | Yes (Managed Sync) | Yes (Managed Sync) |
| Truto | Native forwarding for change events | RapidBridge sync jobs, five-minute minimum; incremental only if configured (as of 8 October 2026) | The changed record on some, such as Microsoft Teams; OneDrive and Google Drive events don't | For OneDrive and Google Drive, a follow-up call since 5 October 2026 | Not by default; an opt-in synced store exists |
| StackOne | Native; webhooks for systems without native ones are "early access, rolling out soon" (as of 8 October 2026) | None on the current platform; its Legacy Unified APIs poll every hour by default, down to 5 minutes where the provider supports time-based filtering | Identifiers for account events; the integration's own shape for integration events, which StackOne can fill with the full record (Native Webhooks, June 2026) | Depends on the integration's payload, unless hydration is set up; legacy polling events send the record ID only | Not on the event path; its separate sync product keeps records for up to 30 days |
| Knit | Virtual (Syncs), plus native events on 18 apps | 24 hours on its entry plan; configurable on Scale Up and Enterprise, 5-minute minimum (as of 8 October 2026) | The changed record, one per call | Not needed | No records, per Knit; keeps hashes of synced records |
| Competitor details are as of the read dates listed for each source 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-changedevent 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 on some integrations that send their own webhooks, such as Microsoft Teams; OneDrive and Google Drive events need a follow-up call (as of 8 October 2026). Its interval option is RapidBridge sync jobs, at a five-minute minimum, which re-fetch everything unless incremental sync is configured.
Which integration platforms support real-time webhooks instead of polling?
Unified.to supports webhooks instead of polling through two paths: native webhooks forward events as the integration sends them, and virtual webhooks detect changes on an interval (minimum 1 minute on paid plans) and deliver events, carrying the changed records where supported, on supported integrations and objects. Among the other platforms above, Apideck, Truto, StackOne and Knit (on 18 apps) forward native webhooks, while Merge and Kombo use source webhooks to update their own stores and notify you from that copy. Where an integration sends no webhooks, change detection is interval-based on every platform that offers it: Apideck's virtual webhooks run "typically every 24 hours," Knit's minimum is 5 minutes, and Paragon's Managed Sync minimum is one minute with identifiers only (competitor details as of the read dates in Sources). For the same question from your application's side, see Best Way to Receive Updates from APIs Without Webhooks.
How does Unified.to handle each model?
Unified.to supports native and virtual webhooks through one API and one payload format. Native webhooks forward the integration's events as it sends them; virtual webhooks, on supported integrations and objects, check for changes at an interval you set, down to 1 minute on paid plans, and a change arrives with the next check. Events carry the changed records where supported, so a follow-up fetch is usually not needed. Deletes arrive on native webhooks where the integration sends them, and on virtual webhooks only on ten integrations, including BambooHR, Google Drive, OneDrive and Box. For retries, billing, the full list of integrations with virtual deletes and how to pair webhooks with reconciliation, see Polling vs Webhooks: When to Use One Over the Other.
Should you rely on webhooks alone?
No: Merge, Kombo, Apideck and Unified.to each recommend pairing webhooks with a periodic reconciliation read to catch what webhooks miss, as their own docs state:
- 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 8 Oct 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 8 Oct 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.
Sources
Vendor pages read 20 September 2026 unless stated.
- Apideck: webhooks guide; virtual webhook interval; CRM webhook events; syncing at scale (all re-read 8 Oct 2026)
- Merge: concepts; Merge webhooks; sync frequencies (re-read 30 Sep 2026; Highest settings re-checked 8 Oct 2026); data storage; syncing best practices
- Kombo: webhooks; how Kombo syncs data; fetching data (all re-read 8 Oct 2026)
- Paragon: Managed Sync webhooks; enable a sync; Managed Sync overview; ActionKit Triggers webhooks (all re-read 8 Oct 2026)
- Truto: webhooks overview; processing webhook events; what makes Truto different; sync jobs; changelog, 15 Jun 2026; changelog, 5 Oct 2026 (re-read 8 Oct 2026)
- StackOne: webhooks; platform events; Data Sync; legacy webhooks; Native Webhooks changelog; StackOne vs Composio (read 8 Oct 2026)
- Knit: pricing; syncs (read 8 Oct 2026)
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.