What a webhook is, and why a liability clause should name it

An API is a question. Your client’s app asks a payments company to charge a card, and the payments company answers. A webhook is the same relationship with the initiative reversed. Something happens on the far side — a transfer lands — and the payments company tells your client’s server, without being asked.

That message is the moment the in-app wallet should change. If the server is down, or the address is wrong, or nobody checked the signature on the message, the bank has the money and the app does not know. Users experience that as a broken product. They complain to the company whose name is on the screen.

The literacy point for a contract is small and easy to miss. A clause that says the company is not responsible for “third-party failures” is abstract. A clause that names the gateway, and says what the product does when a webhook does not arrive, describes the system the engineers are actually running. Whether that clause holds up is a question for instructed counsel on the facts. Knowing that a webhook exists is the prior question, and it is the one this note is for.

Read the APIs lesson on the path if you want the diagram. This note is not advice, and it does not create a solicitor–client relationship.