Routeon Email Overview

Routeon Email is the email channel of the Routeon CPaaS platform: a REST API at https://emails.routeon.io/api/v1 for sending transactional email and one-time passcodes from your application, running marketing campaigns and automations for your contacts, and tracking what happened to every message. You connect your own sending domain, author content as templates that the platform verifies before they can send, and pay for sending from a credit balance. The same account is also managed through the customer portal at https://emails.routeon.io.

What you can build with it

  • Transactional notifications — password resets, receipts, order and account updates sent from your backend with POST /transactional/send, scheduled up to 30 days ahead with send_at (and canceled before they go out), or sent to up to 100 recipients in one call with POST /transactional/send-batch.
  • One-time passcode flows — login, sign-up confirmation or step-up checks with POST /otp/request and POST /otp/verify; code generation, expiry, resend cooldown and the attempt budget are handled for you.
  • Marketing campaigns — one-off sends to lists and segments of your contacts, sent now or scheduled, and paused, resumed or canceled while they run.
  • Automations — multi-step sequences that contacts enter when they are created, added to a list, or match a segment, or when your code enrolls them with POST /automations/{id}/enroll.
  • An audience that stays clean — contacts with custom fields, lists, dynamic segments, bulk import, per-contact export and erasure, custom behavioural events (POST /events), and a suppression list that every send is checked against.
  • Delivery tracking wired into your systems — look up any message and its events with GET /messages/{id}, filter messages by status, recipient, time range or your own tags, and receive webhooks for deliveries, opens, clicks, bounces, complaints, deferrals, failures and unsubscribes, each carrying the tags and metadata you attached at send time.
  • Spend and results reporting — credit balance, activity feed, CSV statements, invoices, and an overview report of your sending results.

What it does — and does not — do

Does:

  • Send email over a REST API, rendered from your templates with per-message variables.
  • Verify template content before a template can be activated, and check the active version again on every transactional send.
  • Connect your sending domain through a mail provider enabled for your account (ses for Amazon SES or kumomta for KumoMTA) and give you the exact DNS records to publish for it.
  • Ramp new domains up through a warmup schedule you can inspect, pause and resume.
  • Check every recipient against your suppression list, and enforce your sending limits and credit balance before a message is accepted.
  • Report per-message status and events, push events to your webhook endpoints, and meter every send against your credits.

Does not:

  • Receive mail. There are no inboxes and no inbound or reply processing; the platform is outbound only.
  • Accept mail over SMTP. You submit messages through the REST API only.
  • Send arbitrary content per request. Every message is rendered from a template that has passed content verification; you cannot pass raw HTML in a send call, and the content check cannot be switched off.
  • Send from domains you have not verified. The From address is always <local_part>@<your verified sending domain>.
  • Re-check your DNS on its own. A domain is verified only when you call POST /domains/{id}/verify (or press Verify in the portal).
  • Deliver over any channel other than email. SMS, voice, push and chat are not part of this API; OTP codes are delivered by email.
  • Let you manage the sending infrastructure. The platform operates the mail servers; your only choice is which enabled provider a domain is connected through.

How it works

  1. Set up access. In the customer portal you create an API key with the scopes your integration needs. Every API request carries it as Authorization: Bearer <API_KEY>.
  2. Connect a sending domain. You register a domain with POST /domains, publish the DNS records the response returns, and call POST /domains/{id}/verify. Once the domain is verified it can send; by default a new domain starts on a warmup schedule. Sender profiles (/senders) define the mailbox name and display name your mail comes from.
  3. Prepare content. You create a template, verify it, and activate it. Transactional sends need a transactional-class template in active status.
  4. Send. Your application calls the transactional, OTP or campaign endpoints. Before accepting a message the platform checks the domain, the template and its content, the recipient against your suppression list, your daily limit and your credits. An Idempotency-Key header makes retries safe.
  5. Track the outcome. Each accepted message gets an id and moves through statuses such as queued, sending, sent and delivered (or bounced, deferred, failed and others). You read it with GET /messages/{id}, or subscribe to webhooks and have the events pushed to you.

Next step

→ Quickstart: send your first transactional email and confirm its delivery through the API in under five minutes.