Retries
Eight attempts over about nine hours, and what your receiver must do.
Your receiver must
- Accept repeats. Univooz can send an event more than one time. Use
idto find a repeat. - Answer
2xxquickly. All other answers are failures. - Do the work after the answer. An answer that takes more than 10 seconds is a failure.
- Not expect a sequence. Use
createdto find old events.
One status change is one event. So a repeat is always the same event again, never two
orders of work. A check on id is therefore always safe.
Univooz does not follow redirects. If your endpoint moves, change the URL in the dashboard.
The retry sequence
Eight attempts over about nine hours. Then Univooz stops.
| After attempt | Next attempt after |
|---|---|
| 1 | 30 seconds |
| 2 | 1 minute 30 |
| 3 | 4 minutes 30 |
| 4 | 13 minutes 30 |
| 5 | 40 minutes 30 |
| 6 | 2 hours 1 minute 30 |
| 7 | 6 hours 4 minutes 30 |
| 8 | Univooz stops |
The dashboard log records each attempt with its response code and the next time.
You can send a stopped message again from the log. It has the same id and the same body.
Your receiver cannot change the API
Univooz puts messages in a queue. So an order is created and answered even when your endpoint does not operate.
A webhook failure never stops a customer's order. You lose only the message, and you can get that again.
After an outage
Do not send each message again one by one. Read the orders instead:
GET /v1/orders?updatedSince=...&updatedUntil=...Read a closed window over the period of the outage. This finds all changes. See Page through lists.