Retries, disabling and resending

Each endpoint gets its own delivery of each event. A delivery goes through these statuses, which appear in the Status column under Recent deliveries:

What counts as a failure is in The response.

Retry scheduleCopy Anchor Link

There are up to 8 attempts per delivery. The first goes out right after the event is created, usually in less than a minute. After each failure, Vipter waits:

The waits are minimums: the queue is processed every minute, so each attempt may go out a little later. If the eighth fails, the delivery becomes exhausted. In practice, an endpoint that comes back up within about 3 days and 8 hours of a failure still receives the event on its own.

Each attempt carries the same body, with the same id and the same created, and a new signature, with the t of the moment it was sent.

Automatic disablingCopy Anchor Link

Vipter counts, per endpoint, the consecutive deliveries that ended as exhausted. When the count reaches 20, the endpoint is disabled and its card shows the reason auto-disabled after 20 exhausted deliveries. A succeeded delivery resets the count.

The count is of exhausted deliveries, not attempts: that is 20 events that failed 8 times each. An endpoint that is down is only disabled after going through the whole schedule for at least 20 events.

To turn it back on, fix your server and turn on the endpoint's Active switch. Turning the switch on resets the count and clears the reason.

Events while the endpoint is disabledCopy Anchor Link

This applies both to automatic disabling and to the switch turned off by hand:

• New events are not kept for it. The endpoint only receives deliveries of events created while it is active. An event created while it is disabled never reaches that endpoint, not even after it is turned back on, and there is no way to resend it.
• Deliveries already in the queue are closed. When their turn comes, they become exhausted with the error endpoint disabled, without trying to send and without counting toward disabling. Turning the endpoint back on does not resume them: use Resend on each one, with the endpoint already active.

The same applies to an endpoint created after an event: it does not receive events from before it was created.

To check what happened during the period, compare your system with the orders, subscriptions and customers lists in the dashboard.

Resend a deliveryCopy Anchor Link

Recent deliveries shows the store's 50 most recent deliveries, from all endpoints. Every row that is not succeeded has the Resend button. When you click it:

1. The delivery goes back to pending with the attempts reset and is sent right away.
2. You see Delivery re-queued..
3. If it fails again, it follows the schedule from the start.

The resend sends the same event, with the same id: your idempotency check treats it as a repeat if it was already processed. The signature is computed at the moment of the resend, with the current secret.

You can't resend a succeeded delivery from the dashboard. Resending to a disabled endpoint closes the delivery right away with endpoint disabled: turn the endpoint on first.

Test eventCopy Anchor Link

The Send test event button creates a new customer.created event, with a fictitious customer and "test": true in data.object. The format is in the catalog.

• It goes to all active endpoints that receive customer.created or all events, and only to those.
• It is sent right away and you see Test event queued.. If it fails, it follows the same retry schedule as a real event and counts toward automatic disabling.
• Each click creates an event with a new id.
• With no active endpoint, the button is disabled.

Remove an endpointCopy Anchor Link

Remove deletes the endpoint, its secret and its delivery history. Pending deliveries stop. To change the URL without losing events, create the new endpoint, confirm it receives the test event and only then remove the old one. In the meantime, both receive the same events, with the same id.

What to do nextCopy Anchor Link

• See how to answer quickly so you don't trigger needless retries.
• Rotate the secret without losing events in Verify the signature.