A practical checklist for webhooks

It comes up on almost every project, usually later than it should. Run through this the next time webhooks comes up.

Most development decisions are really maintenance decisions wearing a different hat. Doing this properly once is usually cheaper than doing it approximately three times.

The checklist

• Webhooks replace polling with something closer to real time
• Always verify the signature before trusting a payload
• Assume delivery can repeat and design for it
• Someone is named as the owner
• There is a date to review it again

Why this earns attention

Webhooks replace polling with something closer to real time. In practice this is a scheduling problem more than a technical one. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

In practice

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about webhooks before you move on:

• Someone can say what the current setup is without going to look
• Webhooks replace polling with something closer to real time — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.