Webhook Definition in Plain Language
A webhook is an HTTP callback. One service sends data to another service as soon as an event happens. In most cases the sender performs a POST request to a URL that you control.
Teams usually discover this topic by searching phrases like what is webhook, what are webhooks, or web hook. All of those terms refer to the same core mechanism: event driven HTTP delivery.
The key value of a webhook is timing. Instead of waiting and polling for changes, your system receives event data immediately when it matters.
Webhook vs Polling
Polling means your app repeatedly asks an API if new data exists. That model can waste requests, increase latency, and create noisy infrastructure costs.
A webhook flips the flow. The source system pushes data only when state changes. This gives faster responses and usually cleaner system design.
Polling still has value for reconciliation, but webhooks should be your first layer for near real time integrations where events trigger actions.
- Polling checks for changes on a fixed schedule
- Webhooks push changes as soon as events occur
- A hybrid model uses webhooks for speed and polling for periodic verification
What a Good Webhook Payload Looks Like
A production payload should contain an event type, a stable event id, event timestamp, and the business object data you need to process the event safely.
Headers matter as much as the body. Providers often include signature headers so your endpoint can verify authenticity before processing data.
When payload structure is inconsistent, integrations break silently. Define schemas and validate incoming fields before moving data to your internal systems.
Retries, Idempotency, and Delivery Safety
Webhook providers retry when they receive non 2xx responses or timeouts. Your endpoint should be idempotent so duplicate events do not create duplicate records.
Store event ids and processing status. If the same event arrives again, return success after a safe no-op instead of executing side effects repeatedly.
During a webhook test session, intentionally return 500 and 429 status codes to validate provider retry behavior and your own processing resilience.
Implementation Checklist You Can Reuse
Start with a request inspector that captures method, headers, query string, and body. Then wire signature verification and strict schema validation before business logic.
Expose clear logs for each request and response pair. This is the fastest way to debug failed events during integration and production incidents.
Treat webhooks as a contract. Version payloads, document expected fields, and keep compatibility when you deploy parser updates.
- Verify signatures before parsing event payloads
- Process events idempotently using event ids
- Return explicit status codes and traceable logs
- Add webhook test cases to CI for critical integrations
Try it with a real request
Turn the guide into a test.
Open a temporary endpoint, send your payload, and inspect exactly what arrived.
Open the tester