Retries & Delivery
Easy2257 webhook delivery guarantees and retry schedule.
Easy2257 attempts each delivery up to 5 times with a widening backoff, then marks it exhausted.
Retry schedule
| Attempt | Sent |
|---|---|
| 1 | Immediately, as the event happens |
| 2 | 1 minute after attempt 1 fails |
| 3 | 5 minutes after attempt 2 fails |
| 4 | 30 minutes after attempt 3 fails |
| 5 | 2 hours after attempt 4 fails |
| none | If attempt 5 fails the delivery is marked EXHAUSTED and is never retried again |
A delivery therefore survives roughly two and a half hours of downtime on your side. Beyond that you need to reconcile from the API rather than wait for a redelivery: GET /v1/solo-accounts/{accountId} gives you current account status, and GET /v1/collab-scenes/{sceneId} gives you current scene status.
What counts as a failure
An attempt fails when your endpoint returns a non-2xx status, when the connection errors, when the request exceeds the 30-second timeout, or when your URL resolves to a private or internal address.
Return 2xx as soon as you have the payload safely queued, and do the real work asynchronously. A handler that takes longer than 30 seconds will be retried even if it eventually succeeds, which is how duplicate processing happens.
Retry sweep
Pending retries are processed by a scheduled sweep that picks up deliveries whose next retry time has elapsed. Each sweep handles up to 50 deliveries, so a large backlog drains over several sweeps rather than all at once.
Each attempt is re-signed at send time with a fresh t timestamp. The body and the event id never change.
Deduplication
Delivery is at-least-once. Deduplicate on event.id, which is stable across every attempt of the same event. Do not dedupe on the signature timestamp: it is regenerated per attempt.
Inspecting deliveries
Delivery history per endpoint, including HTTP status, attempt count, the response body we received, and final state (PENDING / DELIVERED / FAILED / EXHAUSTED), is in the partner portal at partner.easy2257.com/webhooks.