n8n triggers: webhooks vs. polling

Je bouwt een workflow. Alles loopt. Totdat je in productie één van deze dingen ziet:

• je workflow start ineens in korte tijd tientallen keren achter elkaar
• of hij reageert steevast een paar minuten te laat
• of je loopt tegen rate limits van andere diensten aan terwijl je “niets geks” doet

Dan komt de vraag die dit (vrij technische) onderwerp relevant maakt:

Wat voor trigger heb ik eigenlijk?

In n8n vallen triggers grofweg in twee families: webhooks en polling. Ze halen allebei gebeurtenissen binnen, maar ze doen dat op een totaal andere manier.

Het verschil in één zin

Webhook: de bron meldt zich bij n8n zodra er iets gebeurt.
Polling: n8n vraagt op vaste momenten aan de bron wat er veranderd is.

Dat verschil bepaalt hoe je workflow zich gedraagt bij pieken, fouten en belasting.

Webhook: snel, maar gevoelig voor pieken

Bij een webhook zegt een tool: “Als er iets gebeurt, stuur ik het meteen door.”

Wat je meestal ziet in n8n:

• een webhook-URL
• “Listen/Test” dat pas werkt als de bron echt iets stuurt
• termen als “Webhook”, “Instant”, “Push”

Wat dit betekent in de praktijk:

• snelle reactie (secondenwerk)
• gebeurtenissen komen vaak één voor één binnen
• bij veel activiteit krijg je veel starts kort achter elkaar

En daar zit het risico dat je pas merkt als je workflow dingen “echt” doet:

• één piek kan ineens 50 starts veroorzaken
• en elke start kan weer betaalde of gevoelige stappen uitvoeren: CRM-updates, e-mails, externe API-calls, LLM-stappen

Als je workflow daar niet op gebouwd is, krijg je precies de ellende die je níét wilt: dubbele updates, dubbele berichten, extra kosten en sneller rate limits.

Ook belangrijk: sommige bronnen proberen webhooks opnieuw af te leveren bij timeouts. Dan kan dezelfde gebeurtenis twee keer binnenkomen. Je workflow moet daar tegen kunnen.

Polling: voorspelbaar, vaak in batches

Bij polling zegt n8n: “Ik kom elke X minuten kijken wat er nieuw is.”

Wat je meestal ziet in n8n:

• een interval-instelling (“every 1/5/15 minutes”)
• “fetch since last run”
• termen als “Poll”, “Check”, “Fetch”

Wat dit betekent in de praktijk:

• je accepteert vertraging (afhankelijk van je interval)
• de node haalt “alles sinds de vorige keer” op
• en dat is vaak een batch: meerdere items in één keer

Die batches zijn vaak een voordeel. Je hebt namelijk minder n8n executions voor hetzelfde volume. Houdt er in jouw workflow-ontwerp wel rekening mee dat individuele nodes niet overbelast mogen raken.

Voor ProspectPro gebruikers: de ProspectPro Trigger beschikt over een polling-mechanisme en uiteenlopende filters zodat jij complete vrijheid hebt in n8n.

Hoe herken je welk type trigger je hebt?

Kijk eerst naar de node.

Webhook herken je aan:

• webhook-URL / listen / test
• geen interval
• gedrag: starts clusteren rond echte activiteit

Polling herken je aan:

• interval / check every…
• gedrag: starts komen in een ritme, en vaak met meerdere items per run

Twijfel je nog? Check je executions:

• webhooks: veel losse runs (zeker bij pieken)
• polling: minder runs, maar runs met meerdere items (batches)

Je kunt meestal niet kiezen — maar je kunt wél slim ontwerpen

In theorie klinkt het alsof je tussen webhook en polling “kiest”. In de praktijk gebruik je de trigger die jouw bron biedt, en die werkt zoals de node is gebouwd.

Dus de vraag is: wat betekent dit gedrag voor jouw workflow?

Als je trigger een webhook is:

• Wat gebeurt er bij een piek?
• Wat gebeurt er als dezelfde gebeurtenis twee keer binnenkomt?
• Welke stappen zijn duur of riskant als ze dubbel lopen?

Als je trigger polling gebruikt:

• Hoe groot kunnen batches worden?
• Wat gebeurt er als er in één run ineens veel items binnenkomen?
• Welke stappen doe je per item, en waar ga je rate limits raken als je die 30 keer achter elkaar uitvoert?

Praktische checklist voordat je live gaat

Webhook:

• Wat is je plan bij pieken: concurrency, wachtrij, of “later verwerken”?
• Wat is je plan bij dubbel binnenkomen: voorkom dubbele mails/updates/betaalde calls?

Polling:

• Hoeveel items kunnen er per run binnenkomen (batch)?
• Wat is je plan als een batch te groot wordt: splitsen, limiteren, of een sub-workflow per item?
• Waar zitten je duurste stappen per item, en wat gebeurt er als je die 30 keer achter elkaar uitvoert?

Onthoud dit

De belangrijkste punten uit dit artikel op een rij:

• Webhook = snel en direct, maar kan pieken en dubbele afleveringen geven.
• Polling = voorspelbaar en vaak batch-gewijs, maar één run kan zwaar worden en leidt dan sneller tot timeouts, foutmeldingen en rate limits.
• Je kiest het type trigger meestal niet. Je herkent het gedrag, en ontwerpt je workflow zodat kosten, errors en rate limits niet jouw probleem worden.

Handig voor ChatGPT/Gemini

Wil je met een chatbot brainstormen over ProspectPro integraties met n8n? Dan is het handig als ‘ie weet hoe onze node in elkaar zit. Onze code is volledig openbaar, dus dat is geen enkel probleem. Vraag simpelweg of Chat deze linkjes onderzoekt, en je kan los:

n8n: https://n8n.io/integrations/prospectpro
GitHub: https://github.com/ocjanssen/n8n-nodes-prospectpro
NPM: https://www.npmjs.com/package/@bedrijfsdatanl/n8n-nodes-prospectpro
API docs (community node uses this API): https://docs.prospectpro.nl