Email API
An email API is an HTTP interface for sending and receiving mail from your own code. You post a message as JSON, authenticate with a key, and get an identifier back. Everything a mail server would make you manage — connections, retries, authentication records, bounce parsing — is handled behind the call, and the results come back as events rather than as mail you have to read.
At a glance
- Category
- Interfaces
- Transport
- HTTPS with a JSON body, not an SMTP session
- Authentication
- An API key in an authorization header
- Returns
- An identifier you can use to read the message's timeline
- Results arrive
- As webhook events, not as bounce messages
How it works
Your code makes one HTTPS request carrying the sender, the recipients, a subject and a body, or a template identifier and its variables. The service validates it, checks the suppression list, queues the message and answers with an identifier. Delivery happens afterwards, on the service's own connections, with retries and authentication applied for you. What happens next reaches you as events on that identifier — delivered, bounced, complained, opened, clicked — either on a webhook endpoint or by reading the message back.
Why it matters
The alternative is running the mail path yourself, and the work there is not the sending, it is everything around it: connection pools, retry policy, warm-up, key rotation, bounce parsing, complaint feeds. An HTTP call fits the shape of the rest of your application, so failures surface as status codes in the same logs as everything else, and a send is testable in the same way as any other request rather than only against a live mail server.
Example
A service posts a JSON body naming the sender at a verified domain, one recipient, a subject and an HTML part, with an idempotency key so a retried request cannot duplicate the message. The response carries an identifier. Minutes later a webhook arrives saying the message was delivered, and an hour after that another says a link was clicked. The application never opened a mail connection and never parsed a failure notice.
Common mistakes
- 01Calling the API from the browser, which puts a key that can send as your domain in front of anybody who opens the network tab.
- 02Retrying a timed-out send without an idempotency key, which is the usual way one receipt becomes three.
- 03Ignoring the events and polling the API instead, so failures are found by a schedule rather than when they happen.
- 04Sending from an address at a domain that has not been verified, which is refused rather than delivered unauthenticated.
In Rasket
Rasket is an email API for developers: one REST call sends transactional email or a broadcast, and the same account receives mail at your own domain. Email API
Related terms
Frequently asked questions
How is an email API different from SMTP?
SMTP is a session protocol between mail servers, with its own connection handling and reply codes. An email API is one HTTPS request with a JSON body, so it fits the tooling, logging and testing you already use for the rest of your application.
Can an email API receive mail as well?
Yes, when the service supports inbound. You point an MX record at it and each arriving message is parsed and delivered to your code as a webhook rather than sitting in a mailbox.
What happens if my request times out?
You cannot tell from the timeout alone whether the message was accepted. That is exactly what an idempotency key solves: retrying with the same key returns the original response rather than sending again.
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.