Home / Knowledge hub / Webhook
Knowledge hub
Webhook
A URL you hand to another service so it can call you when something happens.
What it means
A webhook is a URL you hand another service so it can call you when something happens. A payment settled. A file finished. A ticket changed.
Most providers call the message an event notification. It saves you from asking over and over whether anything changed. It also means you now run a public endpoint that accepts data from outside your systems.
Why it matters
Teams trust these handlers far more than the evidence justifies. A request arrives claiming to come from a payment provider. The code takes it at its word, then creates orders, grants access or moves money.
Anybody can send a request to that URL. If the only proof it came from your provider is that the body says so, you have no proof at all. Stripe puts it bluntly: verify the signature, or somebody can trigger fulfilment with an event they made up.
How it shows up
Check three things. Do you verify the sender, with a signature you compute over the raw body rather than a shared secret sitting in the URL? Do you validate the payload like any other untrusted input? And does a repeated delivery do the work twice, or does the handler recognise an event it already processed?
Retries are normal, so duplicates arrive whether or not an attacker sends them. Keep the handler small, because every parse, log line and database lookup that happens before verification is work an unverified request can make you do. Outbound matters too. Letting customers choose where you send webhooks builds a feature that calls addresses strangers pick, which is SSRF.
Questions people ask
Webhook, answered
Is a webhook just an API?
It is an API call running the other way. Instead of you asking the provider whether anything changed, the provider calls you when it does.
Which means your webhook endpoint is an API route of your own, and it needs the same care as any other route you expose.
Is a secret URL enough to secure a webhook?
No, although plenty of integrations rely on it. A long random URL leaks through logs, proxies, error reports and anybody who has ever pasted it into a support ticket.
Verify a signature over the request body instead. Then the URL becoming public is an annoyance rather than an incident.
How do I verify a webhook signature?
Compute an HMAC over the exact raw bytes you received, using the shared signing secret, then compare it to the header with a constant-time comparison.
Sign the raw body, not the parsed JSON. Re-serialising changes key order and whitespace, and the signature stops matching for reasons that take a day to find.
Why did the same webhook arrive twice?
Because providers retry. A timeout, a slow deploy or a brief error all produce a second delivery of the same event, and some providers retry for days.
Key your handler on the event id and skip anything you have already processed. Enforce that at the database, not in code that two workers can race through.
Should I do the work before returning a 200?
No. Verify the signature, queue the event, return a success code quickly, then do the real work asynchronously.
Slow handlers time out, the provider retries, and you process the same event repeatedly while your queue backs up.
Related
Terms that sit next to this one
API
The part of your application other software talks to, not a person.
Authentication
Proving you are who you say you are. It answers one question only.
Input validation
Checking that what arrives is the shape and range you expected.
Untrusted input
Anything that arrived from outside your own code, and is therefore suspect.
Rate limiting
Capping how often something can be attempted, per user or per address.
Who can call your webhook endpoint?
Webhook handlers are API routes, and Cyberlop tests them like the rest: authentication, authorisation and input handling, with the proving request attached. Get in touch.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.