Before you invest in webhooks

The advice here is unglamorous, which is probably why it gets skipped. Before you spend anything on webhooks, it is worth confirming a few things are already true.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Budget a little time for it every quarter and it never becomes a project of its own.

Prerequisites

• You can describe the outcome you want in one sentence
• Someone owns it after the work is done
• Webhooks replace polling with something closer to real time
• You have a way to tell whether it worked

Common failure modes

Always verify the signature before trusting a payload. The reasoning matters more than the rule, because the rule has exceptions. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Assume delivery can repeat and design for it. In practice this is a scheduling problem more than a technical one. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

In practice

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about webhooks before you move on:

• Someone can say what the current setup is without going to look
• Always verify the signature before trusting a payload — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.