Retry Behaviour
When B1Link sends a webhook to your receiver endpoint, it expects a timely success response. If that response doesn't arrive, B1Link retries the delivery on a fixed schedule.
Recommendations
- Return 200 OK as soon as you have accepted and stored the webhook payload. Process the data asynchronously if needed.
- Implement idempotency so that receiving the same webhook more than once does not create duplicate vendor records.
Retry Schedule
By default, B1Link makes up to 4 attempts in total: the initial delivery plus 3 retries, with exponentially increasing delay between them.
| Attempt | Delay before this attempt |
|---|---|
| 1 (initial delivery) | None |
| 2 (retry 1) | 1 second |
| 3 (retry 2) | 2 seconds |
| 4 (retry 3) | 4 seconds |
Each attempt is subject to a 30-second timeout by default. If your endpoint hasn't responded within that window, B1Link abandons the attempt and counts it as a failure.
The retry count and per-attempt timeout are configurable per client, and are also clamped so that the full retry sequence completes inside a fixed delivery window. Where your integration uses the defaults, the schedule above is exactly what you will see. If your integration has been configured with different values, those values are agreed with you as part of that configuration. The behaviour itself does not change, only the count and the timeout.
What Triggers a Retry
B1Link retries a delivery when any of the following happen:
- Your endpoint returns any non-2xx response. This includes 4xx responses (e.g. 401, 404, 429) as well as 5xx responses. There is no special case for 4xx: a 4xx response does not tell B1Link to stop sending the event, and the same payload will be redelivered.
- Your endpoint times out (does not respond within the per-attempt timeout).
- The request fails at the transport level (e.g. connection refused, TLS failure).
After the Final Attempt
If the last attempt still fails, B1Link marks the delivery as failed and stops. It is not retried automatically after that. Recovery at that point is a manual resend initiated by B1Link.
This means a receiver endpoint that is unreachable or unhealthy for an extended period will miss deliveries. Don't assume eventual delivery; monitor your endpoint's availability and error rate so an extended outage is caught and can be raised for a manual resend.
Idempotency Is Mandatory
A retried delivery is byte-identical to the original attempt: same body, same event id. There is no separate delivery-id header and no idempotency-key header layered on top of the payload.
Because of this, your receiver must de-duplicate on the event id already present in the payload: onboardingRequestErpEventId. Use it as your idempotency key so that processing the same delivery twice (whether from a retry or an accidental replay) is a no-op the second time.