Webhooks behavior

​

Number of HTTP call sent

Webhook consumers may receive multiple HTTP calls multiple times for the same event, depending on the event.

Whenever a transaction gets in a final state such as failed or success, the related webhooks should happen only once.

However for intermediate state such as pending or action_required, webhooks may be sent more than once. This can happen if the provider data section changed, meaning the HUB2 API got an update from the provider side, but not the kind of update which can help determine the final status of a transaction.

​

In case of HTTP failure

In case the target URL is not reachable for any reason (network failure, unavailability of the remote server, …), the HTTP call will fail.

To overcome this possibility, the HUB2 API has a replay strategy.

​

Replay strategy

Whenever a HTTP failure happen, a webhook is replayed after an initial delay of 60 seconds. Each attempt extends this time exponentially following that piece of code:

exponential(delay) {
	return function(attemptsMade) {
		return Math.round((Math.pow(2, attemptsMade) - 1) * delay);
	};
}

That will give the following delays for each Nth attempt:

1. Wait 1 minute
2. Wait 3 minutes
3. Wait 7 minutes
4. Wait 15 minutes
5. Wait 31 minutes
6. Wait 63 minutes
7. Wait 127 minutes
8. …

​

Timeout

Such a scenario should occur, it will trigger the replay strategy and may be a root cause of receiving multiple times the same webhook.

​

Automatic deactivation

This automatic deactivation is only temporary and aims to maintain constant quality of service of the HUB2 API. To avoid any concerns about the quality of the integration, it is best this never happens.

It’s possible to activate the webhook again at any time via the available API.

To ensure this deactivation never take place, the remote endpoint receiving the webhook must always return a 2xx HTTP code.

Any other response, or no response, will be considered a failure, and after several tries, will disable the webhook automatically.