Delivery lifecycle
Relin records each delivery attempt, the response status, and the final outcome. A failed delivery does not change whether the event was received. It means the receiver did not accept that delivery attempt.
- An event is accepted into the ledger.
- Relin selects matching destinations or recipient endpoints.
- Each endpoint receives a signed delivery attempt when signing is configured.
- 2xx responses are treated as successful.
- Timeouts, network errors, and non-2xx responses can be retried according to the endpoint policy.
- After retry attempts are exhausted, Relin leaves the failure visible for investigation and replay.
Endpoint controls
- Set maximum retry attempts per destination.
- Adjust backoff timing for destinations that need slower recovery.
- Set a per-minute rate limit when a receiver needs slower traffic.
- Pause a noisy endpoint without deleting its configuration.
- Resume delivery after a receiver is healthy again.
- Replay matching events after a customer endpoint or internal service recovers.
When to replay
Replay after you fix a failed destination, deploy a handler bug fix, rotate a bad secret, or need to backfill a time window. Use filters to keep replay scoped to the events that need another attempt.
- Use single-event replay from the event detail page for one known event.
- Use filtered replay from the ledger when a set of events share a source, search term, or time window.
- Use message replay from the Dispatch API when a recipient asks about a specific customer webhook.
Investigation checklist
- Open the failed event or message and check the latest response status.
- Compare the endpoint URL with the receiver your app currently expects.
- Check whether the endpoint was disabled, paused, or rate limited.
- Look for repeated 401 or 403 responses after signing secret changes.
- Replay only after the receiver returns a successful response to a manual or test request.