Transactional email for modern applications

A transactional email is sent because a specific person just did something, or something just happened to their account. They are waiting for it. That expectation is what makes this kind of email different from a newsletter, and it is why delivery speed and reliability matter more than open rates.

What counts as transactional

| Email | Trigger | Time sensitivity | |---|---|---| | One-time password | Login or signup attempt | Seconds | | Password reset link | "Forgot password" request | Minutes | | Email verification | Account creation | Minutes | | Receipt or invoice | Successful payment | Minutes to hours | | Order or shipping update | State change in fulfilment | Hours | | Security alert | New device, changed credential | Minutes |

Newsletters, promotions and drip campaigns are not transactional. Inboxili handles those too, from the campaigns and automation tools in the dashboard. See transactional vs marketing email for where the line sits.

How sending works with Inboxili

Your backend makes one HTTP request per email. Inboxili renders the message, checks the sender, hands it to the delivery provider, and returns a message ID.

curl https://api.inboxili.com/api/v1/transactional/send \
  -H "Authorization: Bearer $INBOXILI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "ada@example.com",
    "from_email": "hello@yourdomain.com",
    "from_name": "Acme",
    "subject": "Your Acme verification code",
    "html_body": "<p>Your code is <strong>{{code}}</strong>. It expires in 10 minutes.</p>",
    "template_data": { "code": "482913" }
  }'

A successful call returns HTTP 200 with a body like {"status": "sent", "message_id": "..."}. Failures return {"error": {"code": "...", "message": "..."}}. The transactional email API page lists every field and error you should handle.

Before your first send

1. Create a workspace and verify a sending domain in the Deliverability Center. Sends from an unverified sender are rejected with sender_not_verified.
2. Create an API key under Settings, Developer, with the transactional:send scope. The full key is shown once.
3. Optionally build a template in the dashboard and reference it by template_id, filling its merge tags from template_data.
4. Register a webhook if you want delivery events such as delivered, bounced and complained pushed to your application.

What to know before you commit

Being specific about limits saves you a migration later.

• One recipient per request (to is a single address).
• No attachments, CC or BCC fields in the API today.
• No SMTP endpoint. Integration is over HTTPS only.
• Each key is limited to 120 requests per minute, and your plan has its own sending limits.
• There is no idempotency key. If a request times out, do not blindly retry, or the user may get two codes.

If those fit your product, the API is quick to integrate and sends are logged per workspace, including failures and provider message IDs.

Deliverability is mostly your setup

Whichever provider you use, inbox placement for transactional mail depends on authentication and content you control: a verified domain with SPF and DKIM aligned to your From address, a DMARC policy, a recognisable From name, and messages that contain only what the user asked for. Inboxili's Deliverability Center walks through the DNS records. We do not promise inbox placement, because no provider can.

Where next

• Implement it: Transactional email API, then your language: Node.js, Python, PHP.
• Pick a workflow: OTP, password reset, invoice.
• Check the full reference in the developer docs.