Webhooks vs polling: why some integrations are instant and others lag

A client signs an engagement letter and the welcome email goes out within seconds. A new invoice is paid and the CRM does not hear about it for a quarter of an hour. Both run on the same automation platform, so the team assumes something is broken.

Usually nothing is. The difference is how each automation learns that something happened. With a webhook, the source app sends a message the moment an event occurs, so the automation runs straight away. With polling, the automation asks the app "anything new?" on a schedule, so it can only be as fast as that schedule. Which one you get depends mostly on what the source app supports, and then on your plan. Once you know which is which, you can decide where speed matters and stop chasing delays that are by design.

The two ways an automation hears about a change

Polling is the automation platform checking in. Every few minutes it asks the source app for its latest records, compares them with what it has already seen, and runs for anything new. Zapier's help article on how Zap triggers work describes this: most triggers are polling triggers, and Zapier uses a process called deduplication, comparing each item's unique ID with the IDs it has already received, to decide what is new.

Webhooks reverse the direction. The source app calls the automation platform when something happens, sending the details with it. Zapier calls these instant triggers and marks them with a lightning bolt in the editor. Make's webhooks help page says that by default, when Make receives data on a webhook, the scenario runs immediately.

A useful picture: polling is checking your letterbox every 15 minutes; a webhook is the courier ringing the doorbell.

Why the same platform behaves differently

Whether a trigger is instant is decided by the source app's API, not by you. Zapier's article says the trigger type is fixed: if an app only offers a polling trigger for "new invoice", you cannot switch it to instant. That is why two Zaps on the same account can behave so differently: one starts from an app that sends webhooks, the other from an app that has to be asked.

For polling triggers, your plan sets the pace. As listed in Zapier's help center in October 2026, polling intervals are:

Source: How Zap triggers work, as listed in October 2026. Paid plans can also adjust a Zap's polling frequency in its settings, as described in Zapier's article on controlling when your Zap runs.

In Make, a polling trigger runs on the schedule you set for the scenario, and the shortest interval allowed depends on your plan, so check your plan's limits on Make's pricing page. Each scheduled check also uses credits even when it finds nothing, which our article on what a Make scenario really costs to run works through with examples.

Native integrations follow the same rules. Some built-in syncs between two apps run on a fixed schedule set by the vendor, and you cannot speed them up. Check the integration's help page before you promise a client that a payment will show up "instantly".

Webhooks are faster, but not free of trade-offs

Instant does not mean effortless. Things to know before you design around a webhook:

• Plan requirements on the sending side. Not every app lets you send webhooks on every tier. HubSpot's workflow webhook action, for example, needs Data Hub Professional or Enterprise, as listed in October 2026.
• Retries can deliver the same event twice. The same HubSpot article says failed webhooks are retried for up to three days. That is helpful when your automation was briefly down, but the receiving end must recognize an event it has already handled, or it will create a second invoice or send a second email. Our guide to syncing data between apps without duplicates covers the safeguards.
• Queues have limits. If Make cannot process webhook data straight away, it waits in a queue. Make's webhooks page says the queue size depends on your plan, up to 667 items per 10,000 monthly credits and a maximum of 10,000 items, and that data over the limit is rejected once the queue is full, as listed in October 2026.
• Order is not guaranteed by default. Make runs instant webhooks in parallel unless you turn on "Process data in order" in the scenario settings. If an "updated" event can arrive before the "created" event finishes, that matters.
• The address is the key. Anyone who has a webhook URL can usually post to it. Keep URLs out of shared documents, and where the sending app supports it, use its signature or secret to verify that messages are genuine.

Polling has its own blind spots

Polling is simpler and works with almost any app, but it is easy to misread:

• It only sees the state at each check. If a record is created and changed twice between polls, the automation sees the latest version, not each step.
• It does not backfill. Zapier's trigger article notes that Zaps do not run on data created before the Zap was turned on.
• Large batches can be held. The same article says Zapier's flood protection may hold a large batch of runs for review rather than process them immediately, which looks like a delay to the person waiting.
• "Updated" triggers are fussier than "new" triggers. Detecting a change depends on the app exposing a reliable last-modified field. When an update trigger seems to miss edits, this is usually why.

How to decide which you need

Most firms do not need everything to be instant. Ask of each automation: what does a 15-minute delay actually cost?

Worth making instant:

• Replies to new enquiries, where speed affects whether a prospect books.
• Appointment confirmations a client is waiting for on screen.
• Handoffs a colleague is actively waiting on, such as a signed engagement letter that unlocks onboarding.

Fine on a schedule:

• Syncing paid invoices to the CRM for reporting.
• Nightly or hourly updates to dashboards.
• Copying documents into archive folders.

For the schedule-friendly group, a slower interval is often better: fewer checks, fewer credits used, and easier to reason about. For the instant group, check first whether the source app offers a webhook or instant trigger. If it does not, a faster polling interval on a higher plan is usually the practical answer, rather than a custom build.

When an automation seems slow

Before assuming it is broken:

1. Check the trigger type. Look for the lightning bolt in Zapier, or whether the Make scenario starts with a webhook or a scheduled module.
2. Check the interval on your plan and in the Zap or scenario settings.
3. Check the run history for held, queued or errored runs.
4. Check the source app for its own delay, such as records saved as drafts that only count as "new" once finalized.

If runs are failing rather than lagging, set up alerts so someone hears about it the same day; our article on monitoring Zapier and Make automations covers how.

How Flow Mesh helps

Every engagement starts with a first call, then a stack audit scoped in writing before it starts. It gives a verdict on every tool, including which of your automations need to be instant and which are paying for speed they do not use, plus a written scope for any changes. Builds are quoted in writing after the audit and carried out inside your own accounts.

Key takeaways

• Webhooks push events the moment they happen; polling checks on a schedule, so it can only be as fast as its interval.
• The source app's API decides whether a trigger can be instant; your plan decides how often polling triggers check.
• Webhooks need duplicate protection, because retries can deliver the same event more than once.
• Polling sees only the latest state at each check and does not backfill older records.
• Make instant only what a delay would genuinely cost you; run the rest on a sensible schedule.