Email Sending API (2026): A Production Guide to Rovela

What a production email sending API needs — verified domain, send-only keys, idempotency, webhooks, batch, caps — and how Rovela’s POST /emails provides them.

What to expect from an email sending API

“Email sending API” is the head term people type when they want a production way to send mail from software: a URL, a key, a JSON body, and a delivery story they can operate. Rovela’s answer is the Email API — POST https://api.rovela.dev/emails — plus the surrounding pieces you actually need in production: a verified domain, idempotency, webhooks, batch, and (if you want them) mailboxes.

This guide is the production checklist behind that search. It is not the definition pillar in Transactional Email API, not the HTTP-vs-SMTP protocol intro in HTTP Email API, and not Send Your First Email in 5 Minutes. Start from the Email API product page, the Quick Start, the Send Email API, and Authentication. Current plan limits live on pricing.

The contract, in one request

curl -X POST https://api.rovela.dev/emails \
  -H "Authorization: Bearer re_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "Acme <hello@yourdomain.com>",
    "to": "you@example.com",
    "subject": "Hello from Rovela",
    "html": "<p>It worked.</p>",
    "text": "It worked."
  }'

You need: a verified from domain, Authorization: Bearer re_…, and at least one of html, text, or template. The response is a message id. Full field list: Send Email API. There is no official SDK (Installation).

What a production sending API has to include

Use this as a buying-and-building list, then map it onto Rovela (all of the following is documented):

Authenticated sending on your domain. Dashboard DNS for SPF, DKIM, DMARC, and return-path; unverified from is 400. See Verified Domain Email API.
A send-only credential. sending_access can queue mail and nothing else — the default, and the right production sending key. full_access is for reads and management. Keys can be restricted to one domain (Authentication).
Safe retries. Idempotency-Key, 24 hours, 256 characters (Idempotency Keys for Email APIs).
An explicit accept vs delivered split. 200 means queued. GET /emails/:id / events need full_access. Webhooks push email.delivered, email.bounced, and the rest (Transactional Email Webhooks).
A batch path for personalized transactional fan-out. POST /emails/batch, up to 100, no template / topic_id (Batch Transactional Email API).
A marketing path that is not a transactional loop. Broadcasts add list fan-out, suppression, and List-Unsubscribe (Transactional vs Marketing Email).
Hard caps you can code against. 50 recipients per message (to+cc+bcc); quota charged per recipient; 429 when you exceed the rate limit (batch entries count individually).
Optional inbox. Hosted mailboxes and mailbox SMTP if people must read you@yourdomain.com (Transactional Email API + Hosted Mailboxes).

Custom return path (SPF alignment) is included on Pro and Enterprise, not on the free plan, per pricing. Do not assume dedicated IPs or an official SDK — they are not listed as product features on the pages we used.

How this differs from SMTP, relays, and running your own stack

If the question is “API or SMTP?” read Email API vs SMTP and, for a cutover, Migrate SMTP to an Email API. If the question is “must I assemble a mail platform myself?” see A Simple Transactional Email API and Self-Hosting a Mail Server. Rovela mailbox SMTP (mx.rovela.dev:465) is for mailboxes, not a high-volume app relay (SMTP).

A minimum production integration

The same steps as Email API Integration, kept short here:

Verify the domain, store a sending_access key on the server, wrap POST /emails.
Attach an Idempotency-Key per user action.
Register webhooks for email.bounced and email.complained; verify signatures (Verifying Webhook Signatures).
Use batch or scheduled_at only where those APIs fit; do not invent a client-side sender.

const res = await fetch("https://api.rovela.dev/emails", {
  method: "POST",
  headers: {
    Authorization: "Bearer " + process.env.ROVELA_API_KEY,
    "Content-Type": "application/json",
    "Idempotency-Key": `signup-verify:${userId}:${codeId}`,
  },
  body: JSON.stringify({
    from: process.env.MAIL_FROM, // e.g. "Acme <no-reply@yourdomain.com>"
    to: user.email,
    subject: `Your Acme code: ${code}`,
    html: `<p>Your verification code is <b>${code}</b>. It expires in 10 minutes.</p>`,
    text: `Your verification code is ${code}. It expires in 10 minutes.`,
    tags: { kind: "signup-otp", userId },
  }),
});
if (!res.ok) {
  const err = await res.json();
  throw new Error(`Rovela ${res.status}: ${err.message}`);
}
const { id } = await res.json(); // accepted and queued — not yet delivered

FAQ

Is “email sending API” different from “transactional email API”? In search, often not. In product language, transactional emphasizes why the message exists (a user action); “sending API” emphasizes the interface. Rovela’s sending API covers transactional mail and also broadcasts for marketing.

Can I start on the free plan? Yes. The free plan includes 100 emails a month, one domain, the full API, webhooks, inbound, and five mailboxes, with no card required (pricing, Quick Start).

How do I send from Node, Python, or curl? Same HTTP contract: Send Email with curl, Send Transactional Email from Your App, plus the existing language guides.

Ship against the contract, not against a library

Pick an email sending API for the production properties above, then implement the HTTP contract once. With Rovela that contract is POST /emails, a verified domain, and the documented keys, caps, and webhooks.