A payment provider sends a webhook when an invoice is paid. Your automation receives it, updates the order, and emails the customer. Then the provider sends the same webhook again, because your server took too long to reply. The customer gets two emails, and the order history shows two payments.
A webhook is a message one system sends to another when something changes: a payment, a new form submission, a signed contract. It is often the fastest way to connect tools. It also arrives on the sender's schedule, sometimes late, sometimes twice, and occasionally from someone pretending to be the sender.
Check that it really came from the sender
Most services sign each webhook with a secret that only you and they know. Verify that signature before doing anything else, and reject messages that fail. Also reject messages with an old timestamp, so a recorded message cannot be replayed later.
Keep the signing secret in a password manager or secrets store, like any other credential. Our guide to service accounts and expiring access covers where it should live and who owns it.
Reply quickly, then do the work
Senders usually wait only a few seconds for a reply. If your automation updates three systems before answering, the sender may assume it failed and send it again.
Instead:
- Verify the signature.
- Save the message with its unique ID.
- Reply that it was received.
- Process it in the background.
Make repeats harmless
Assume every webhook can arrive more than once. Before acting, check whether you have already processed that message ID or that business event, such as "invoice 1042 paid." If so, reply that it was received and do nothing else. Our guide to retries without duplicate actions explains the pattern in more detail.
Also expect messages out of order. A "payment refunded" event can arrive before "payment completed." When order matters, look up the current state in the source system rather than trusting the message alone.
Notice when webhooks stop
The quietest failure is no messages at all: a changed URL, an expired secret, or a sender that disabled your endpoint after repeated errors. Track when the last webhook arrived, and alert the owner if none comes during a period when one would be expected. Many senders also offer a periodic list of recent events; compare it with what you received, in the same way as a batch reconciliation.
Keep a short log
For each message, record when it arrived, its ID, the event type, and the result: processed, ignored as a repeat, or failed. Do not store more personal data than you need. When something goes wrong, this log is how you find out which events were missed.
To review the webhooks behind your automations, email Storm Nova Labs.
