Order confirmations and e-tickets, sent from your app
A simple API for the emails your product sends — on the same trusted infrastructure, with templates, logs and tracking.
What transactional email in MailNesto does
Transactional emails are the ones a single customer triggers: an order confirmation, an e-ticket, a password reset, a one-time code, an invoice. They are expected, often urgent, and usually the most-read emails a business sends. If an OTP arrives five minutes late, the customer has already given up.
With MailNesto, your app sends them with one HTTPS call — either its own HTML, or a template designed in the builder plus the data for this order. Every message is queued, sent through your account’s delivery servers with DKIM, retried if the receiving server is busy, and logged with what happened to it.
Because it is the same account as your marketing, receipts and newsletters share one contact profile, one suppression list and one set of authenticated domains. Transactional mail is still treated as its own thing: it isn’t held back when marketing sending is paused, and it reaches people who unsubscribed from newsletters.
Transactional email, done properly
A clean REST API
One call to send. Use a saved template with data, or send your own HTML. Batches of up to 100 at once.
Attachments & scheduling
Attach invoices and tickets, schedule a send for later, and avoid duplicates with idempotency keys.
Searchable message log
Every message with its status, opens, clicks and the exact content that was sent.
Webhooks
Delivered, opened, clicked, bounced and complained events posted to your server, signed and retried.
Same reputation, separate stream
Transactional mail keeps flowing even when marketing is paused.
Scoped keys
Read-only or full API keys, with IP allow-lists and usage per key.
One call to send, up to a hundred in a batch
POST /transactional/send takes a recipient, a subject and HTML or text — or a templateId and a data object — authenticated with an API key sent as a bearer token. The response comes back at once with the message’s id and the status “queued”, and delivery follows in the background.
POST /transactional/batch accepts up to 100 messages in one request. Each is checked on its own, so one bad address doesn’t sink the rest; the answer lists which were accepted and why any were refused. Add an idempotency key — your order number works well — and a repeated request returns the message already created instead of sending twice, which matters when a checkout retries after a timeout.
- Recipient as an address, or a name and address
- From and reply-to per message, or your workspace defaults
- Schedule a send up to 72 hours ahead with sendAt
- A tag (receipt, otp, ticket) and up to 20 metadata fields per message
Design once, fill with each order’s data
Build a receipt or ticket template in the drag-and-drop builder and call it by id. Whatever you pass in data becomes a merge tag: an order object with an id and a total fills {{order.id}} and {{order.total}}, and a list of items becomes comma-separated text. Fallbacks work as in campaigns, so {{first_name|there}} still reads naturally when a name is missing.
If the recipient is already a contact, their saved fields — city, plan, birthday — are available too, with the values you send taking priority. Conditional blocks work as well, so one order template can show a cash-on-delivery note only when the payment field says COD. The API’s template list shows which merge tags each template uses.
- Subject from the template or from the call
- Plain-text version generated from the HTML when you don’t send one
- Up to 10 attachments, 7 MB in total — invoices, tickets, statements
Sent at once, retried, never to the wrong people
Messages are sent straight from the queue, and the log records how many seconds each took from your call to the receiving server. If that server answers with a temporary error, MailNesto tries again after 30 seconds, 2 minutes and 10 minutes. A permanent rejection, such as an address that doesn’t exist, fails at once with the server’s reason.
Before sending, each message is checked against your suppression list and the platform blocklist; a match is marked “suppressed” instead of being sent. A newsletter unsubscribe doesn’t block a receipt, because a receipt isn’t marketing, but a hard bounce or spam complaint suppresses the address automatically. For one-time codes, switch off open and click tracking on the call so the email stays plain.
- Signed with DKIM from your authenticated domain
- Executable attachments (.exe, .bat, .js and the like) refused, as mailbox providers block them
- Daily sending limits respected — messages wait rather than fail
- Failed messages can be sent again from the log
Every message, its content and what happened
The Transactional page shows sent, opened, clicked, bounced or spam, and not sent for the last 24 hours, 7 days or 30 days, with a daily volume chart, the median time to send, and a table by tag — so you can compare OTPs with order confirmations at a glance.
Search the log by recipient, subject or message id, and filter by status, tag and date. Opening a message shows the exact subject and body that went out, the template, the server, the number of attempts, the receiving server’s message id and each open and click. When a customer says “I never got my ticket”, support can answer in a minute.
- Statuses: queued, sent, failed, suppressed, bounced and complained
- Messages kept for 30 days; the log exports as CSV
- A “Send a test” button on the page
- A link from each message to the contact’s profile
Tell your app what happened
Subscribe a URL to transactional.sent and transactional.failed, and to email.opened, email.clicked, email.bounced and email.complained, which carry the message id, your tag and the metadata you attached. Each delivery is signed with your endpoint’s secret, retried with growing gaps if your server is down, and kept in a delivery log you can resend from.
API keys can be full or read-only and limited to your servers’ IP addresses, so a leaked key is of little use elsewhere. A read-only key suits a dashboard that only lists messages; the key that sends belongs on your back end, never in a mobile app or web page.
- Your metadata, such as order_id, returned in every event
- Last-used time shown for each key
- Revoke one key without touching the others
Up and running in three steps
- 1
Create a key
In Developers → API keys.
- 2
Design a template
With merge tags for order numbers, names and links.
- 3
Call the API
POST /transactional/send — and you’re live.
Transactional email for every kind of business
A Surat saree store on its own website sends an order confirmation with the invoice PDF attached, tagged “receipt”, and a shipping update tagged “shipping”, then compares the two in the tag table.
A comedy promoter in Pune emails each buyer their ticket as soon as payment succeeds, using the payment id as the idempotency key so a repeated payment callback never sends two tickets.
A Hyderabad start-up sends sign-up codes and password resets with tracking switched off, and watches the median time to send to make sure codes arrive while the user is still on the screen.
A dental clinic’s booking software schedules a reminder for the evening before each appointment with sendAt, and hears about a wrong address through transactional.failed so the front desk can call instead.
A coaching centre emails fee receipts and test results from its student system; because templates can use the student’s saved fields, one template serves every batch.
A developer wiring up a client’s checkout uses a full-access key limited to the server’s IP for sending and a separate read-only key for a small status page, and can revoke either alone.
- REST API with API keys
- Templates with dynamic data
- Batch sending
- Attachments
- Scheduled sends
- Idempotency keys
- Message log and search
- Delivery webhooks
- Open and click tracking (optional)
- Tags and metadata
- IP allow-lists
- Usage alerts
A common set-up is two separate services: a marketing tool for newsletters and a developer-focused sending API for receipts and codes. That means two places to authenticate domains, two suppression lists that drift apart, and customer history split in half — the marketing side never sees that someone just bought, and support has to search two logs.
In MailNesto both run from one account. Transactional templates are designed in the same builder as campaigns, a hard bounce from a receipt suppresses that address for newsletters too, and the contact profile shows transactional messages next to campaigns and orders. Transactional mail is still handled differently where it should be: it ignores newsletter unsubscribes and keeps going when marketing sending is paused.
Tips for better results
- 1
Tag every message by type — otp, receipt, ticket, reset — so the overview shows which kind has a problem.
- 2
Use your order or payment id as the idempotency key, so retries in your own code can’t send duplicates.
- 3
Turn off open and click tracking for codes and password resets; there is nothing to measure, and plain links are more trusted.
- 4
Send from an address people recognise, such as orders@yourbrand.in, with a reply-to that a person actually reads.
- 5
Put the key detail — the code, the order number, the event date — in the subject or first line so it shows in the phone notification.
- 6
Keep attachments small. A one-page PDF invoice is fine; a large brochure is better as a link.
- 7
Handle transactional.failed in your app, for example by asking the customer to check their email address at checkout.
- 8
Never put an API key in a mobile app or browser code; send from your server.
Questions about transactional email
Is there an SDK?
The API is plain JSON over HTTPS, so any language works. The API docs include examples for curl, JavaScript, Python and PHP.
Are transactional emails affected by marketing limits?
They’re sent on their own stream and keep flowing if marketing sending is paused.
Do unsubscribed contacts still get transactional email?
Yes. Unsubscribing ends marketing email, not the receipts and tickets a customer asked for. Addresses on your suppression list — hard bounces, spam complaints or ones you added — are never emailed, and those messages show as “suppressed” in the log.
How quickly are messages sent?
They are queued and sent straight away, and the overview shows the median time from your API call to the receiving server for your own account. How fast the email then appears in the inbox is up to the recipient’s mailbox provider.
What if the receiving server is temporarily unavailable?
MailNesto retries three times — after 30 seconds, 2 minutes and 10 minutes. If every attempt fails, or the server rejects the address permanently, the message is marked failed with the reason and a transactional.failed webhook is sent.
Can I schedule a transactional email?
Yes, with sendAt, up to 72 hours ahead — handy for a reminder the evening before an appointment. For anything further out or recurring, an automation with a date trigger is the better fit.
How long are messages kept?
Thirty days, including the content as sent. Attachments are not stored once a message has been sent or has failed, so a failed message with attachments has to be sent again from your app.
Can I use templates I made for campaigns?
Yes. Any saved template in the workspace can be used by id, and the API’s template list shows each one’s merge tags. It is worth keeping transactional templates in their own folder so a marketing edit never changes a receipt by accident.
Do transactional emails count towards my monthly allowance?
Yes — each message counts as one email on your plan, the same as a campaign email, and test messages from the page count too. See pricing for the allowance on each plan.