A developer-first REST email API running on Indian infrastructure. Idempotent sends so retries never duplicate an OTP, real-time webhooks for every delivery event, 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 an idempotent request: a unique identifier you generate per logical send. If the platform sees the same identifier twice, it returns the original result instead of sending again. neuMails supports this through request IDs, and using it costs one line of code.
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 delivered, opened, clicked, bounced and complained events to your endpoint in real time. Three of those require action on your side:
Two implementation details worth getting right. Verify the signature on incoming webhooks — 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.
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, idempotency guarantees, rich per-message metadata, or you're in a serverless environment. Many teams use both on one account.
Through idempotent requests. 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. Submitting a unique request ID per logical send means a repeat returns the original result instead of sending again.
Delivered, opened, clicked, bounced and complained, in real time. Handle hard bounces and complaints 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.