Webhook

A callback that tells your system the moment a decision is ready.

Instead of repeatedly checking whether a verification has finished, your system gives the verification service an address, and the service sends a message to that address as soon as there is a result.

An HTTP callback delivering asynchronous verification events to a subscriber endpoint. HTTP is the standard way web systems talk to each other, asynchronous means the result arrives later and not as an immediate reply, and a subscriber endpoint is the web address your system exposes to receive the message.

A webhook flow typically works like this:

1. Your system registers a URL with the verification service and chooses which events to receive.
2. A user completes verification, and the service reaches a decision.
3. The service sends an HTTP request to your URL with the event details.
4. Your system acknowledges the message and acts on it, such as approving the account.

Reliable webhook handling uses a few common practices:

• Signature checks, so your system can confirm a message really came from the service and was not forged.
• Retries, since the service resends a message if your system does not acknowledge it.
• Idempotent handling, which means processing the same message twice does not cause a double action.
• Fast acknowledgment, so slow processing does not cause unnecessary retries.

A webhook sits next to terms that are easy to mix up:

• Polling is the alternative, in which your system asks the server repeatedly whether the result is ready.
• Software development kit (SDK) is the component that captures data in the app, while a webhook returns the decision to your server.
• Orchestration coordinates the flow, and webhooks are one way it reports results.