Use this workflow when a recipient reports a missing message, a webhook event is unexpected, or your application needs to reconcile delivery state.
Capture the identifiers
Store these values when you send a message:
| Identifier | Where it comes from | Why it matters |
|---|
request_id | API response and webhook payloads | Connects the send request to later delivery events. |
smtp_id | Webhook payloads when present | Helps correlate SMTP and API delivery records. |
| Sender and recipient | Request payload | Narrows the investigation to a domain, mailbox, or user. |
Follow the event sequence
- Confirm the API returned a successful response for
send or send-async.
- Search your stored webhook events by
request_id.
- Confirm a
processed event exists.
- Look for an event such as
delivered, hard-bounced, soft-bounced, dropped, or complained.
- If the recipient says the message is missing after a
delivered event, ask them to check spam, quarantine, forwarding
rules, and mailbox-level filters.
delivered means the receiving mail system accepted the message. It does not guarantee inbox placement or that the
recipient saw the message.
Missing webhook events
If the API returned a successful response for send or send-async, but your system did not record a webhook event:
- Confirm the webhook endpoint is still enrolled.
- Run webhook validation from the Console or the API.
- Check whether your endpoint returned a non-2xx response, timed out, or rejected the request before storing the raw payload.
- Query webhook batches for recent failed delivery attempts.
- Use batch resend after you fix the receiver.
Recipient says the message was not received
Collect this information before escalating:
- Sender address and recipient address.
- Approximate send time with time zone.
- API
request_id.
- Last webhook event and timestamp.
- Whether the recipient checked spam, junk, quarantine, forwarding, and mailbox rules.
- Any bounce or complaint event.
Review errors for more request troubleshooting. 
