A developer-first REST email API running on Indian infrastructure. Per-recipient event tracking on every send, real-time webhooks for delivery, deferral, bounce and suppression, and dedicated IPs so your reputation is your own. Billed in INR with GST invoices.
SMTP is a stateful conversation from 1982: your client opens a connection, greets the server, declares a sender, declares each recipient, transmits the body, closes. Five or more round trips, on a connection that must stay open throughout.
An email API is a single stateless HTTPS request. One round trip, one response, done. That architectural difference produces most of the practical distinctions:
Note the last row runs the other way. If you already have an application sending mail — WordPress, Django, Laravel, a legacy ERP — switching to SMTP relay is a credentials change, while adopting an API is a refactor. Plenty of production systems use both: SMTP for the monolith, the API for new services. Both run on one neuMails account with unified logs and suppression.
Longer treatment of the trade-off in What Is an Email API?
This is the failure mode that generates support tickets, and most integrations don't handle it.
Your service submits an OTP send. The request succeeds server-side, but the response is lost to a network timeout. Your retry logic fires. The user now receives two codes — and depending on your implementation only one is valid, so roughly half of affected users enter the wrong one and fail to log in.
The fix is a deduplication key you control: a unique identifier you generate per logical send — the OTP's own record ID works well — written to your store before you call the API. If your retry path finds that key already marked sent, it returns the stored result instead of submitting again. Keep the check on your side of the network boundary, because that is the side that survives a lost response.
Be clear-eyed about what the platform does and doesn't do here. The neuMails API does not deduplicate repeated identical requests: an identical second call produces a second message ID and a second email. Every accepted send returns a message_id, so record it against your key and you have the reference to reconcile against email logs later.
Design your retries deliberately alongside it:
Teams routinely ship the send path and skip the receive path. The result is an application that believes every email worked.
The API delivers seven event types to your endpoint in real time: injection when we accept the message, delivery when the recipient's server accepts it, deferred on each temporary failure, bounce on permanent failure, suppression when an address was blocked before sending, plus open and click. Events are per-recipient — on a multi-recipient send each address generates its own events with its own event ID, all sharing one message ID.
Three of them need handling beyond logging:
Two implementation details worth getting right. Verify the signature on incoming webhooks — every request carries an HMAC-SHA256 digest of the raw body, and an unauthenticated endpoint that mutates your subscriber database is an obvious attack surface. And make handlers idempotent, because webhook delivery is at-least-once; the same event will occasionally arrive twice, and a naive handler double-counts.
When webhook state and application state disagree, email logs are the reconciliation source. Payload shapes and signature verification samples are in the API documentation.
For a login code or a payment confirmation, the user is watching a screen. Seconds convert directly into abandonment, and two things determine those seconds.
Routing. Mail sent through infrastructure in Virginia or Dublin to a recipient in Mumbai makes a round trip of thousands of kilometres before it starts the delivery conversation. neuMails runs on AWS Mumbai, so mail to Indian recipients doesn't leave the country to come back to it.
Queue priority. Transactional mail is prioritised over bulk in our delivery queue, so an OTP doesn't sit behind a 200,000-recipient campaign that started thirty seconds earlier. This is why the separation below matters operationally as well as reputationally.
If your marketing campaigns and your OTPs share a sending domain and IP pool, a badly targeted promotional send that generates complaints will degrade the reputation delivering your login codes.
Nobody marks an OTP as spam. They inherit the damage anyway, and it's rarely diagnosed quickly because few people connect Tuesday's campaign to Thursday's login failures.
Use separate subdomains and separate IP pools — mail.yourdomain.com for system mail, news.yourdomain.com for campaigns. One platform is fine; shared reputation is not. See transactional email and bulk email for how the two differ in practice.
Using an API doesn't exempt you from SPF, DKIM and DMARC. Gmail and Yahoo require all three from bulk senders regardless of how the mail was submitted, and enforce a spam complaint threshold of 0.3 percent with 0.1 percent as the warning zone.
If those records are missing or misconfigured, no amount of good API design will get your mail delivered. Our authentication wizard generates the records, and the Gmail and Yahoo requirements guide covers the full checklist.
Message data, delivery logs and subscriber records are stored and processed on AWS Mumbai (ap-south-1). Nothing crosses a border, the vendor relationship is domestic, and data-flow documentation is available for audits and customer security questionnaires.
Where your requirement is that data must not leave your own network at all — rather than simply staying in India — the platform can be deployed on-premise in your data centre. More on the regulatory picture on our DPDP compliance page.
The first two lines determine whether your mail arrives. The rest determine whether you find out when it doesn't.
Free trial includes full API access. No credit card required.
Start Free TrialAn HTTP interface that lets your application send email and retrieve delivery data programmatically. You authenticate with an API key, submit a request describing the message, and receive a response identifying that send. Delivery outcomes arrive later through webhooks.
Use SMTP when an existing application already sends mail and you only need a configuration change. Use the API when you need immediate accept or reject feedback in one round trip, rich per-message metadata, or you're in a serverless environment. Many teams use both on one account.
By deduplicating on your side of the network boundary. If a response is lost to a timeout and your retry fires, a naive integration sends the code twice and the user may enter the wrong one. Generate a unique key per logical send, record it before you call the API, and check it in your retry path. The neuMails API does not deduplicate repeated identical requests — an identical second call produces a second message and a second email — so the check has to live in your application.
Seven event types in real time: injection, delivery, deferred, bounce, suppression, open and click. Events are per-recipient, each with its own event ID. Handle hard bounces by suppressing the address in your own database too — platform-side suppression doesn't stop your application attempting the send.
Infrastructure runs on AWS Mumbai, so mail to Indian recipients doesn't round-trip through a US or European data centre first. For an OTP where someone is waiting on a checkout screen, that routing difference is the practical distinction between a completed and an abandoned transaction.
Yes. Authentication is a property of your sending domain, not your integration method. Gmail and Yahoo require all three from bulk senders regardless of whether mail arrives over SMTP or HTTP.
They can share a platform but shouldn't share a sending domain or IP pool. Marketing complaints degrade the reputation that delivers your OTPs, so keep the streams on separate subdomains with separate reputation.
On AWS Mumbai (ap-south-1). Message data, delivery logs and subscriber records remain on Indian servers. Where data must stay inside your own network, the platform can be deployed on-premise.