A webhook is an automatic message that one system sends to a web address you set up as soon as a particular event occurs, for example a payment or a submitted form. The receiving system can then react immediately, such as marking an invoice as paid. Webhooks are the counterpart of querying through an API.
How does a webhook work?
Think of a doorbell. Instead of checking every five minutes whether someone is at the door, it rings when someone is there. With an API you ask (pull); with a webhook you are notified (push).
Technically it takes a few steps. In the sending system you enter the web address of your receiver and choose the events you care about. When one occurs, the system sends a message to that address, usually as an HTTP request with data in JSON format. The receiver confirms receipt with a success response and processes the data. For APIs in general, read What is an API?.
| Feature | API query (pull) | Webhook (push) |
|---|---|---|
| Who starts? | Your system asks | The other system reports |
| When? | At fixed intervals or on demand | Immediately when something happens |
| Effort | Many queries with nothing new | Only for real events |
| Risk | Delay until the next query | Message can fail or arrive twice |
| Example | Fetch yesterday's orders | Payment received, invoice updated at once |
Where are webhooks used in business?
Webhooks connect tools without anyone copying data. When a payment arrives at the payment provider, your system marks the invoice as paid and sends the confirmation. When a visitor submits the website form, the CRM creates the contact. When an appointment is booked, it appears in the calendar and your team gets a message. What such a path from website to CRM looks like is described in Why your website should feed a CRM.
Payment providers and developer platforms document their webhooks in detail, for example Stripe and GitHub. The advice there on signatures and retries applies by analogy to other services.
How do you set up a webhook?
First decide which event should trigger which action, for example: payment received, then mark the invoice as paid. Then enter the receiver's address and the secret key in the sending system. Send a test message and check in the log that it arrives and is processed correctly. Most providers offer test events and a history of sent messages for this.
Without custom development you can do it with automation tools that provide a receiving address and chain actions together. For important processes such as payments or invoices, a properly built receiver that reports errors and tolerates retries is worth it.
What matters for security?
A webhook receiver is a publicly reachable address. Anyone could send messages there and fake events. Never rely on the content alone.
The main rules: use only encrypted connections (HTTPS). Verify the signature that many providers send along. It is derived from the message and a secret key that only sender and receiver know. Check the timestamp so that old messages cannot be replayed. Confirm receipt quickly and process the data afterwards. Store keys securely and never in public code.
If personal data is sent to external services, you generally need a data processing agreement. This is not legal advice. If you want to connect systems, see our business systems service.
- Events named that should trigger a reaction
- Receiver address reachable only over HTTPS
- Signature and timestamp of every message checked
- Duplicate delivery recognised and processed only once
- Outages noticed and missed events caught up
- Secret keys protected and renewed regularly
- Data protection and data processing agreement checked
Conclusion: get notified instead of asking
Webhooks save queries and speed up processes when they are properly secured and monitored. Start with one event, such as the form, and extend as needed. If you want to know which connection is worthwhile for your business, describe your process.
