Synthetic teaching example for a website delivery brief. Not a client result, live account test or certification.
Which link in the delivery chain actually has evidence?
A website can accept an enquiry while its notification email fails later. Another email can reach the recipient’s mail server without reaching the inbox or being read. When commissioning a new form workflow, ask for a message-level evidence trail, not only a successful HTTP response or a “sent” badge.
| Message | Supplied events | Finite report |
|---|---|---|
| M-DEMO-1 | sent, delivered, exact repeated delivered | RECIPIENT_SERVER_DELIVERED; human read UNKNOWN |
| M-DEMO-2 | sent, bounced | BOUNCED |
| M-DEMO-3 | sent only | PENDING |
Use the filled example
Download the finite Node checker and filled input. Run with Node 24 or newer; no account, API or network is used.
node checks.mjs enquiry-email-status-ledger enquiry-email-status-ledger.jsonThe ledger records three message IDs and six event rows, including one exact duplicate. The checker reports duplicateEventRows 1 and preserves the three different delivery states. Reusing one event ID for a different record raises a conflict. If both delivered and bounced are supplied for one message, the result is REVIEW_CONFLICT rather than guessing a final state from array order.
Turn the test into a website delivery requirement
Agree how an accepted enquiry receives a reference and how its notification message is related to that reference. Then require a redacted provider event, a review queue for permanent failures and an operational owner for a missing event. Do not retry blindly without a deduplication rule; a retried notification must not create a second enquiry or customer record.
A real authorised test should separately verify storage, provider acceptance and delivery evidence. Human acknowledgement and qualified-enquiry status need their own record. A provider delivery event cannot establish a sale, a reply or the identity of a person who read it.
This demonstration sends no email and reads no inbox or provider account. Its field names are a simplified teaching adapter, not a complete Resend webhook payload or a chronological state engine. A provider-specific implementation must handle verified events, late delivery, conflicting evidence and retention securely.
Primary facts and limits
Resend webhook event types: email.sent means accepted for an attempted send; email.delivered means delivery to the recipient mail server, not human reading.
Sources reviewed 15 October 2026. The supplied input and acceptance rules are original teaching design; check current platform versions and your actual delivery contract before implementation.