Email API: what it is and when to use one

An email API lets your application send a message with an HTTPS request instead of opening an SMTP connection. You post JSON, you get JSON back, and the provider handles queueing and delivery.

API or SMTP

| | Email API | SMTP | |---|---|---| | Transport | HTTPS request | SMTP session (ports 25, 465, 587) | | Errors | HTTP status plus a structured body | SMTP reply codes, often asynchronous bounces | | Fits | Code you control | Software with an SMTP settings screen | | Template and merge data | Usually a request field | Done before sending | | Connection handling | Your HTTP client | A library or MTA |

If you are writing a backend today, the API is simpler. If you are configuring an existing CMS, printer, or legacy system, SMTP is often the only option, and Inboxili cannot serve that case yet.

What to check in any email API

1. Sender authentication. Can you verify your own domain and sign with DKIM?
2. Failure semantics. Does a 200 mean accepted or delivered? Is there an idempotency key?
3. Events. Are delivered, bounced and complained events available as webhooks, and are they signed?
4. Limits. Rate per key, recipients per call, attachments, message size.
5. Key security. Scopes, rotation, IP restrictions.
6. Separation. Can transactional traffic be kept apart from marketing sends?

How Inboxili answers those

• Domains: DKIM, SPF and DMARC records are set up from the Deliverability Center.
• Semantics: HTTP 200 with status: sent means the provider accepted it. Delivery outcomes arrive by webhook. No idempotency key yet.
• Events: delivered, opened, clicked, bounced, complained, unsubscribed, delayed, signed with HMAC-SHA256 in the X-Inboxili-Signature header.
• Limits: 120 requests per minute per key, single recipient, no attachments.
• Keys: scopes, optional expiry, per-key IP allow and block lists, instant revocation.
• Separation: API sends are logged separately from campaigns.

Details and examples are on the transactional email API page.