Sending API & SMTP
The API your product already wanted.
One JSON POST, or the SMTP relay if your code already speaks SMTP. Replies come back to a human.
Two ways in
A REST endpoint for new code, and an SMTP relay for everything that already sends mail and should not be rewritten.
- HTTP: a bearer token and a JSON body
- SMTP: credentials per workspace, standard submission
- Idempotency keys, so a retry does not send twice
- Per-key permissions, so a key that only sends cannot read mail
Replies land somewhere
Every message we send carries a signed reply address that points back at your workspace. When a customer replies to a receipt or a password reset, it arrives in your team inbox threaded under the message that caused it.
- No noreply@ address, and no reply lost
- The token is signed, so nobody can guess an address and staple mail onto your thread
- Your own reply_to always wins if you set one
- A reply that says only “unsubscribe” suppresses the address automatically
You can see what happened
Delivery, opens, clicks and replies are recorded per message, with signed webhooks for your own systems and an event timeline you can poll.
- Signed webhooks for delivery events
- Per-message status and event history over the API
- Hard bounces and complaints suppress the address without anyone deciding to
Not in v1
What this page does not claim.
- First-party SDKs — the API is REST and SMTP, documented with curl, JavaScript, Python and Go examples
- A dedicated sending IP
- Agent mailboxes — planned for the next release