Event reference

Every event has the same envelope:

{
  "type": "email.delivered",
  "created_at": "2026-08-09T22:15:47.538Z",
  "data": { }
}

data depends on type.

Email

Event When
email.queued Accepted and waiting to send.
email.sent Handed to the mail server. Not delivered.
email.delivered The receiving server accepted it. As close to "arrived" as email gets.
email.delivery_delayed Temporarily undeliverable; still being retried.
email.bounced Permanently undeliverable. The address is suppressed.
email.complained Reported as spam. The address is suppressed.
email.rejected Refused before sending.
email.failed Could not be sent.
email.cancelled A scheduled send was cancelled before it went.
email.suppressed Not sent, because every recipient was on the suppression list.
email.rendering_failure The template could not be rendered — usually a variable problem.
email.opened The tracking pixel was fetched. See tracking for why this is a weak signal.
email.clicked A tracked link was followed.

The two that matter

email.bounced and email.complained. Both mean stop emailing this person, both suppress the address automatically, and both should be reflected in your own database — otherwise your product keeps believing it can reach someone it cannot.

email.delivered is useful for "did the password reset go out". Everything else is reporting.

Sent is not delivered

email.sent means the mail server took the message. email.delivered means the recipient's server accepted it. Between the two, mail is routinely rejected. If you are showing a user "we sent you an email", key it off sent; if you are deciding whether to fall back to SMS, wait for delivered.

And neither means anyone read it. Nothing in email means that.

Contacts

Event When
contact.created Added to a list.
contact.updated Changed, including subscribing and unsubscribing.
contact.deleted Removed from a list.

contact.updated is what tells you someone unsubscribed. If your product has its own notion of marketing consent, this is the event that keeps the two in step.

Domains

Event When
domain.created Added.
domain.verified DNS checks passed; the domain can send.
domain.updated Settings changed.
domain.deleted Removed.

domain.verified is useful if you onboard customers who bring their own domain — it is the moment their sending starts working.

Testing

Event When
webhook.test You pressed the test button.

Sent through the same signing and retry path as everything else, so if webhook.test verifies, your verification is correct.

Something here wrong or missing? It is generated from the running API — tell us and we will fix the source.