The warmup governor
Daily send caps are now enforced on the accept path rather than described in the schema. Accounts start at 200 messages a day and climb one rung at a time as their sending stays clean, reviewed once a day against the previous day.
Going over the cap returns 429 with a Retry-After pointing at the reset, and GET /v1/me now reports your limit and how much of it you have used, so nobody has to discover the cap from their first refusal.
Signed webhooks, with retries that give up sensibly
Events are pushed as they happen, signed with a timestamped HMAC over the raw body so a captured request cannot be replayed.
Failed deliveries retry on a backoff and carry a stable idempotency key across attempts. A 410 or 404 from your endpoint stops delivery immediately rather than retrying into a wall for twelve hours.
Inbound bounce handling
Every message goes out with a unique return path, so a bounce is attributed to the exact send rather than guessed at from the recipient address.
Delivery status notifications and complaint reports are parsed, attributed and recorded. Permanent failures suppress the address immediately; temporary ones never do.
Sending, end to end, on our own infrastructure
The full path is live: API to a Postgres-backed queue, to our own MTA, to the recipient’s mail server over an encrypted connection, with the SMTP conversation kept.
Messages are DKIM-signed per domain at the transport layer, so the signature covers the exact bytes that go on the wire.
Being built next
- A dashboard, so the delivery record is readable without an API call.
- A Node SDK with the webhook verification built in.
- Dedicated IPs with guided warmup for the top tier.
Dates are deliberately absent. Ask if one of these is blocking you and we will tell you honestly where it is.