Webhooks: the questions we get asked most

The version of this that works is simpler than the version most people imagine. The questions about webhooks that come up most often on our calls.

Most development decisions are really maintenance decisions wearing a different hat. If it only works because one person remembers to do something, it does not work yet.

Do we need to care about this?

Webhooks replace polling with something closer to real time. It is worth being explicit about, because assumptions differ quietly. It rarely shows up as a line item, which is exactly why it slips.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. Small and consistent beats large and occasional here.

How do we know it is working?

Assume delivery can repeat and design for it. 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.

What this looks like day to day

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
• Assume delivery can repeat and design for it — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.