Webhook retries
LX CloudPos aggressively retries failed deliveries in order to avoid losing relevant events. There are two layers: in-process retries (in-memory, immediate) and persistent retries (cron, spaced out over time).
In-process (synchronous)
Right after the original delivery, LX CloudPos makes up to 3 attempts with linear backoff:
| Attempt | Wait before |
|---|---|
| 1 | 0 s |
| 2 | 2 s |
| 3 | 8 s |
Persistent (cron)
If the 3 in-process attempts fail, the delivery is placed in a persistent queue, with the last known Hacienda status saved so the same payload can be resent. A cron job every 10 minutes drains that queue, up to a total of 5 attempts (3 in-process + 2 by cron).
This means that if the receiver was down for a few minutes, the event is still delivered afterward: the receiver does not need to be online at the exact instant Hacienda resolves the document.
When it is retried
| Receiver response | Retried? |
|---|---|
2xx (200, 201, 204) | No (success) |
4xx except 429 | No (definitive receiver error) |
429 | Yes (rate limited) |
5xx | Yes (transient failure) |
| Timeout (>10 s) | Yes |
| Connection refused | Yes |
When retries stop
- After the total of 5 attempts (3 in-process + 2 by cron).
- If a
4xxother than429is received on any attempt (definitive error). - If the
webhookUrlfails SSRF validation (forbidden URL).
Each delivery includes the
intentofield in the payload and anonceunique per attempt. The deduplication logic must tolerate redelivery of the same event.