Why it shows up in your week
A webhook is where many automations either become reliable or quietly lose data. The event fires once, but the receiving system still has to prove it arrived, passed verification, and can be replayed if something failed.
In plain language
Think of a webhook as an event message. A payment provider, CMS, booking tool, CRM, or form system sends a request to your application when a specific action happens.
The hard part is handling duplicates, downtime, vendor retries, invalid signatures, partial failures, and the person who needs to know what happened on Tuesday.
Where it bites
Webhooks bite when an integration looks simple in a demo but has no record of failed events. Orders, leads, documents, or status changes go missing and nobody knows whether the source system sent them.
What to check
- Does the receiver verify webhook signatures before trusting the event?
- Can the workflow handle duplicates, retries, and out-of-order events safely?
- Where can a person see failed events and replay them without guessing?
Common questions
What is a webhook?
A webhook is an HTTP request one system sends to another when a defined event happens, such as a payment, form submission, booking, or publish action.
How is a webhook different from an API?
An API is usually requested by the receiving system. A webhook is pushed by the source system when an event happens.
What should you check first for webhooks?
Check signature verification, retries, idempotency, failure logs, replay, and who owns the integration when the vendor changes the payload.