Webhook vs polling in n8n. When to use which

Every n8n workflow starts with a trigger. The choice between a webhook trigger and a scheduled poll is usually made based on what’s easier to set up, not what’s correct for the use case. That creates problems later.

Use a webhook when: you need to react immediately to an event. Form submission, CRM record created, deal stage changed, payment processed. The external system pushes data to n8n the moment the event happens. Latency is milliseconds.

Use polling when: the external system doesn’t support webhooks, or when exact timing doesn’t matter and you want to process records in batches. A scheduled run every 15 minutes pulling new Clay table rows is a polling pattern. Fine for enrichment jobs. Wrong for time-sensitive signals.

The practical difference: a pricing page visit webhook fires within seconds. A polling workflow checking for new web visits every 15 minutes means the fastest possible response is 15 minutes after the visit, and on average it’s 7.5 minutes. At scale, that averages out to thousands of signals being actioned late every day.

A few things worth knowing about webhook setup in n8n:

Webhooks in n8n need to be reachable from the internet. If you’re self-hosting n8n locally, you’ll need a tunnel (ngrok for testing, proper reverse proxy for production). n8n Cloud handles this automatically.

Always add authentication to inbound webhooks. A shared secret header that the sending system includes with every request. Without this, anyone who discovers your webhook URL can trigger your workflow.

For high-volume webhooks, add a queue between the receiving endpoint and the processing logic. n8n handles moderate volume fine, but if a CRM event fires 500 times in a minute, you want a buffer.

One pattern I use often: receive the webhook, write the payload to a staging table, process from the staging table on a schedule. Decouples the ingestion from the processing and gives you a replay mechanism if something breaks.