Je wacht op een webhook. Hij komt niet. Nu ben je aan het gokken wat er gebeurd is.
Een gemiste webhook is bijna nooit de schuld van de provider — het is bijna altijd een lokaal probleem dat je systematisch kunt opsporen. Hieronder de meest voorkomende oorzaken, een diagnose-volgorde, en hoe je herhaling voorkomt.
De meest voorkomende oorzaken
Jouw server was even niet bereikbaar
Een release, een korte storing, een queue-spike — de provider belt aan en krijgt geen antwoord. Drie tot vijf retries later geeft hij het op. Voor jou voelt het als "ze hebben niets gestuurd", maar het is "ik kon niet opnemen".
Time-out: je server reageerde te traag
De meeste providers verwachten een 200-respons binnen 5 tot 30 seconden. Doet je applicatie eerst de hele verwerking, dan kun je over die tijd heen. De provider markeert dat als mislukt en herhaalt — of geeft op.
Signature-validatie weigerde de aanroep
Een mismatch in je signature-check stuurt elke webhook stilletjes naar de bit-bucket. Vaak veroorzaakt door een verkeerd geconfigureerde secret, een proxy die headers strip, of een verschil in body-encoding.
Firewall of proxy blokkeerde de IP
Sommige providers verzenden vanaf wisselende IPs. Een te strikte allowlist of een ingestelde web application firewall kan ze weigeren — vaak zonder duidelijke melding aan jouw kant.
Diagnose in vier stappen
Check het dashboard van de provider
Vrijwel elke provider (Stripe, Mollie, GitHub, Shopify) toont een log van verzonden webhooks met response-status. Daar zie je direct of de webhook is verstuurd, of jouw server antwoordde, en wat de respons was. Dat scheelt urenlang gokken.
Bekijk je server-logs op het verwachte tijdstip
Krijg je geen 200 te zien in het provider-dashboard, kijk dan in je server-logs. Een 4xx-respons wijst op iets in je applicatie (vaak signature-validatie), een 5xx op een crash of timeout, en geen log betekent dat de request je server niet eens bereikte.
Test handmatig met curl of het provider-testendpoint
De meeste providers hebben een "stuur een test-webhook" knop. Geen mooie 200 als response? Dan ligt het bij jouw endpoint. Wél een mooie 200 maar live ontvang je niets? Dan ligt het bij timing, throughput of validatie van échte events.
Vraag bij twijfel om een resend
Stripe en Mollie kun je vragen specifieke webhooks opnieuw te versturen vanuit hun dashboard. Goede tussenstap als je iets hebt gefixt en wil verifiëren dat het nu werkt.
Hoe WebhookFlow herhaling voorkomt
Onmiddellijk antwoorden, later verwerken
WebhookFlow accepteert binnen milliseconden en geeft 200 terug — geen time-out meer. Pas daarna sturen we het door naar jouw applicatie, in een tempo dat jij aankan.
Persistente buffer bij downtime
Is jouw server tijdelijk niet bereikbaar? WebhookFlow houdt de melding vast en probeert het automatisch opnieuw, dagen lang als dat nodig is. Geen permanent verlies bij een release of korte storing.
Signature-validatie aan onze kant
WebhookFlow valideert de signature volgens de spec van de provider, vóór doorzending. Configuratie eenmalig op het dashboard; geen kans meer op subtiele validatie-bugs die individuele events laten verdwijnen.
Veelgestelde vragen
Hoe weet ik of een webhook nooit verzonden is, of dat ik hem alleen gemist heb?
In het dashboard van de provider zie je het altijd. Staat de webhook in hun log met "delivered: success"? Dan heeft hij jouw server bereikt en is hij door jou afgewezen of verkeerd verwerkt. Staat hij op "failed"? Dan heeft jouw kant niet kunnen reageren. Staat hij er helemaal niet? Dan was er een probleem aan de provider-kant of trigger-configuratie.
Hoe lang blijft een provider proberen?
Wisselt per provider. Stripe probeert tot 3 dagen. Mollie probeert urenlang. GitHub probeert enkele uren. SendGrid stopt na enkele pogingen. Géén enkele provider probeert eeuwig — dus als jouw server een halve dag offline is mis je permanent events. Een buffer ertussen lost dat structureel op.
Helpt het om mijn endpoint te versnellen?
Zeker, en doe dat altijd. Verwerk de webhook asynchroon (queue + worker) en geef binnen milliseconden 200 terug. Het lost niet alle problemen op — downtime, signature-issues en firewall-blokkades blijven — maar elimineert de meest voorkomende oorzaak (timeout).
Wat is het verschil tussen webhook ontbreekt en webhook niet verwerkt?
Een webhook die ontbreekt is nooit bij je applicatie aangekomen (provider geeft op, jouw server gaf timeout, firewall blokkeerde). Een webhook die niet verwerkt is wel aangekomen maar verkeerd afgehandeld (database-fout, validatie-mislukt). De diagnose-aanpak is verschillend; voor de eerste help een buffer, voor de tweede betere error-handling en monitoring.
Mis nooit meer een webhook
WebhookFlow is in ontwikkeling en zoekt beta-gebruikers. Meld je aan voor vroege toegang.