# Delivery events

Track recipient outcomes and keep provider acceptance separate from actual delivery.

Source: https://docs.ravenrelay.joshlab.site/delivery-events

Agent index: https://docs.ravenrelay.joshlab.site/llms.txt
OpenAPI: https://docs.ravenrelay.joshlab.site/openapi.json

## Understand the states

| State | Meaning |
| --- | --- |
| queued / processing | Stored and waiting, or claimed by the worker. |
| sent | The delivery provider accepted the message. |
| delivered | The recipient mail server accepted the message. |
| delayed | Delivery is delayed; this is not a final bounce. |
| soft_bounced | A transient bounce; no automatic suppression. |
| hard_bounced | Permanent bounce; the address is suppressed. |
| complained | Spam complaint; the address is suppressed. |
| rejected / failed | Provider rejection or processing failure. Inspect the failure code. |
| suppressed | Blocked before sending. |
| simulated | Legacy test-mode processing; no external delivery. |

Recipient outcomes are tracked individually. A hard bounce or complaint survives later or out-of-order delivery events. Delivery cannot confirm inbox placement or that the email was read.

## Inspect the timeline

Open an email in the dashboard to inspect its chronological events and per-recipient outcomes. Duplicate delivery notifications are handled without duplicating the business event. Webhooks use a stable event ID, so receivers must also deduplicate and tolerate out-of-order events.