Anypostdocs
Sign inStart sending
Docs/Get started

Introduction

Anypost sends email for your application: password resets, receipts, notifications, product announcements. It tells you what happened to every message, and it's built to be quick to integrate, dependable at volume, and cheap enough that you never have to ration your sending.

What Anypost does

Sending email well is harder than running an SMTP server. Mail from an unknown server gets filtered as spam, authentication (SPF, DKIM, DMARC) is easy to get subtly wrong, and once a message leaves your app you have no idea whether it landed. Anypost handles that:

  • Deliverability: verified sending domains, automatic DKIM signing, and reputation management so your mail reaches the inbox.
  • Delivery feedback: every message produces events (delivered, bounced, complained, opened, clicked) that you can react to in real time.
  • Operational tooling: suppression lists, open and click tracking, reusable templates, and analytics, none of which you have to build.

It fits a wide range of needs. A new application can wire straight into the HTTP API. An existing app, or off-the-shelf software that already speaks SMTP, can point at Anypost's SMTP service instead and get the same delivery and reporting without any code changes.

Two ways to send

Anypost accepts mail two ways, with near-identical capabilities. Pick whichever fits your stack; everything Anypost reports back is the same regardless of how a message arrives.

TransportHow you sendBest for
HTTP APIA JSON request to POST /v1/email.New code. The richest option, and what most of these docs describe.
SMTPAuthenticate with an API key and submit mail the way any email library already does.Existing apps and off-the-shelf software you'd rather not change.

The mental model

Four concepts cover almost everything in Anypost. Once they click, the rest of these docs are detail.

  1. Domains. A sending domain is a domain you own that Anypost is authorized to send mail for. You verify it once by adding a few DNS records. From then on your mail is properly authenticated.

  2. API keys. Every send is authenticated with an API key. One key works for both transports: it's the bearer token for the HTTP API and the password for SMTP. Keys are scoped (sending only, or limited to specific domains) and can be rotated whenever you need to.

  3. Send. With a verified domain and an API key, you send a message: one request to POST /v1/email, or an SMTP submission. Anypost accepts the message, authenticates it, and hands it off for delivery.

  4. Events. Delivery is neither instant nor guaranteed, so Anypost reports back. As a message progresses it emits events: email.delivered, email.bounced, email.complained, email.opened, email.clicked, and more. You receive these as webhooks (an HTTP POST to your endpoint) or browse them in the dashboard.

The flow is always the same: domains, then API keys, then send, then events.

Send your first email

Once you have a verified domain and an API key, sending over the HTTP API is a single request:

curl https://api.anypost.com/v1/email \
  -H "Authorization: Bearer $ANYPOST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "[email protected]",
    "to": ["[email protected]"],
    "subject": "Hello from Anypost",
    "text": "It worked."
  }'

A 202 response means the message was accepted for delivery. The body returns a message id and a created_at timestamp:

{
  "id": "email_018f4f3e-7b2c-7c80-8e21-1a3a4f5b6c7d",
  "created_at": "2026-04-30T12:00:00.123000Z"
}

A 202 is not a guarantee of delivery. It means Anypost has the message. What happens next arrives as events. Use the id to correlate every event back to the message that produced it.

Where to go next