Email Pipeline

How a Notify send moves from your API call through delivery events, logs, and webhooks.

This page describes the operational path of a transactional email in Notify — not a compliance brochure. Know what happens after POST /api/email/send.

High-level path

  1. Accept — Your request hits the send API with x-api-key, to, subject, message (optional from, replyTo, …)
  2. Authorize — We validate the key, plan quota, and (for custom from) domain verification
  3. Queue / handoff — The message is accepted for delivery through our sending infrastructure
  4. Deliver — The provider attempts delivery to the recipient’s mail server
  5. Observe — Events appear in email logs; subscribed webhooks fire on Pro/Scale
Your app  →  POST /api/email/send  →  Accept + quota checks
                                      ↓
                                 Delivery infrastructure
                                      ↓
                    Recipient MTA  ←  Delivery / Bounce / Delay
                                      ↓
                         Logs API + Dashboard (+ Webhooks)

Sandbox vs production

| Path | Endpoint | Counts toward quota | Custom from | | --- | --- | --- | --- | | Test | POST /api/email/send/test | No | Softened for onboarding | | Production | POST /api/email/send | Yes | Requires verified domain |

See Sandbox vs Production.

Events you can observe

Typical lifecycle events (names as used in webhooks/logs):

  • Send — accepted by Notify
  • Delivery — accepted by the recipient’s mail server
  • DeliveryDelay — temporary delay
  • Bounce — rejected
  • Complaint — marked as spam
  • Open / Click — engagement (when tracked)

Free plan: dashboard/API logs with 48-hour retention. Pro and Scale: permanent logs. Webhooks: Pro (up to 3) and Scale (up to 10).

Retries

  • Your HTTP client should retry transient 5xx / network failures on the send API with backoff (and treat successful accepts as done — do not double-send without idempotency in your app).
  • Downstream delivery may experience provider-level retries for temporary failures (DeliveryDelay). Permanent failures surface as bounces.
  • Webhook delivery today is best-effort push to your URL. Make your endpoint idempotent. Webhook requests are not HMAC-signed yet — use secret URLs and HTTPS; correlate with message_id via the logs API when you need stronger checks. See Webhooks.

Suppression

Hard bounces and complaints can land addresses on a suppression list so you do not keep hammering bad mailboxes. Treat suppressions as a deliverability signal, not a marketing preference center.

What Notify does not do

  • Compose your HTML or host a template studio
  • Manage auth tokens, magic links, or Stripe invoices for you
  • Replace a full ESP marketing suite

You own content and product logic. We own the delivery pipe and observability surface.

Where to next?