Retries
A delivery is received when your endpoint answers with a 2xx status within 10 seconds (3 to connect). Anything else is a failure, and we try again:
- any other status,
3xxincluded: we don’t follow redirects, so point the endpoint at the final URL; - no answer within the time, a connection refused, or TLS older than 1.2;
- a URL whose host name resolves to a private or reserved address: we don’t connect to it.
The schedule
Section titled “The schedule”| Mode | Attempts | When |
|---|---|---|
| Live | 16 over about 3 days | At once, then after 1, 5, 15 and 30 minutes, then 1, 2, 3, 4, 6, 6, 7, 8, 10, 12 and 12 hours |
| Test | 4 over about 2.5 hours | At once, then after 5 minutes, 30 minutes and 2 hours |
Each wait varies by up to 10%, so retries of many events don’t arrive all at once. Every attempt carries the same event id and a new PSP-Signature; PSP-Delivery-Attempt says which attempt it is.
A change of the endpoint applies to the next attempt: a new URL, a new API version (the event is shaped in it), a rolled secret.
When attempts run out
Section titled “When attempts run out”A delivery whose last attempt fails stays failed. Read what you missed with GET /events?delivery_success=false, or send it again from the endpoint’s Event deliveries in the merchant portal, for up to 30 days:
- Resend sends one delivery again, whatever its status, as soon as it can: right away, or just after an automatic attempt of it that is under way or about to start;
- Resend failed sends again every delivery of the endpoint that failed, or was canceled while the endpoint was off, oldest first, 10 a second, up to 10,000 at a time.
From your code, POST /events/{id}/retry with the endpoint’s id resends one event, as Resend does; so does novaro events resend (Test locally with the CLI).
A resend is a new attempt with the same event id, shaped in the endpoint’s API version when it goes. It doesn’t change the schedule: a delivery still being retried keeps its next attempt, and one already canceled that has automatic attempts left goes back on the schedule if the resend fails. An endpoint that is off takes no resend: turn it on first.
An endpoint that has received nothing for 24 hours is marked failing, and we email your account’s admins and developers (live mode only). After 72 hours, and 10 failed attempts at least, we turn it off: it gets nothing until you turn it on again, and its deliveries waiting for a retry are canceled. Once it is on, Resend failed sends them; the events made while it was off have no delivery: read them with GET /events?created[gte]=….
Rolling back an API version
Section titled “Rolling back an API version”For 72 hours after you change an endpoint’s API version, you can roll it back to the one before, from the endpoint’s page in the merchant portal. The deliveries that failed since the change, in the new version, go again in the old one: 10 a second, up to 10,000 (send the rest with Resend failed); the rest keep their schedule. An endpoint that is off is rolled back and sends nothing.