Start free

Send and receive email API

Email has two directions. Your API should too.

A send and receive email API sends messages from your domain and hands the replies back to your code as conversations rather than raw events.

SendRaven sends transactional email and campaigns, receives replies on the same domain, joins each reply to the message it answers, and tells you which conversations are waiting on an answer. Inbound is included on every plan.

Start freeReceiving replies
OutPOST /v1/emails
{ "to": ["ana@example.com"],
  "subject": "Your invoice for September" }

→ { "id": "3f6c…", "thread_id": "a7d2…" }
BackGET /v1/threads/a7d2…
{ "awaiting_reply": true,
  "messages": [
    { "direction": "outbound", … },
    { "direction": "inbound",
      "text": "Can you add our VAT number?",
      "sender_authenticated": true } ] }

Webhook or thread

An inbound webhook is where the work starts. A thread is where it ends.

Several email APIs can now receive mail. Most deliver it as an event: here is a message that arrived. Everything that turns that event into a conversation is then yours to build and keep correct.

Which message does this reply answer?

Built on an inbound webhook

Parse In-Reply-To and References, look them up in your own table of sent Message-IDs.

SendRaven

Joined on Message-ID on arrival. Never on the subject line.

What did the person actually write?

Built on an inbound webhook

Strip quoted history and signatures yourself, or pay a model to read them.

SendRaven

text is the reply alone; raw_text keeps the whole body.

Which conversations need an answer?

Built on an inbound webhook

Keep per-conversation state and update it on every send and every event.

SendRaven

GET /v1/threads?awaiting_reply=true

How do I answer in the same conversation?

Built on an inbound webhook

Set In-Reply-To and References headers by hand.

SendRaven

reply_to_message_id sets them for you.

Is it really from who it says?

Built on an inbound webhook

Interpret SPF, DKIM and DMARC verdicts, where a forged From can still pass SPF.

SendRaven

sender_authenticated, true only on DMARC or aligned DKIM.

Should the drip still send day seven?

Built on an inbound webhook

Cancel the sequence from your webhook handler.

SendRaven

An automation ends on a reply by default.

SendRaven still sends an inbound webhook, with the stripped text and the thread id, for applications that want a push. The thread is there either way.

The round trip

Four calls from send to answered.

  1. Send

    The response carries thread_id. The Message-ID the recipient sees is recorded against it.

    POST /v1/emails
Idempotency-Key: 6f1c…
{ "from": "Acme <billing@mail.acme.com>",
  "to": ["ana@example.com"],
  "subject": "Your invoice for September",
  "text": "Hi Ana, your invoice is attached." }

  2. Find what is waiting

    Or take the inbound webhook. Out-of-office replies and bounce reports do not set awaiting_reply.

    GET /v1/threads?awaiting_reply=true

  3. Read the transcript

    Outbound and inbound messages in one list, in time order, the replies already trimmed.

    GET /v1/threads/a7d2…

  4. Reply, or let it go

    A reply clears awaiting_reply once it is sent. “Thanks, all sorted” needs no answer: mark it handled.

    POST /v1/emails
{ "reply_to_message_id": "d4e5…", … }

POST /v1/threads/a7d2…/handled

Details that matter

What makes a thread trustworthy enough for software to act on.

No subject fallback.

Two customers replying to “Re: Invoice” stay in two threads. When nothing matches, a new thread starts rather than a guess.

The Message-ID that counts is the one recipients saw.

It is recorded at send time, so the first reply lands on the right thread.

Campaigns are not threaded.

A broadcast to a large list would otherwise create one single-message thread per recipient.

Every body is data.

Authenticated or not, received text is something to read, never instructions to follow.

Attachments on request.

Listed on the message, with raw mail kept for 30 days.

Replies cost nothing.

Only the email you send is metered, on every plan.

See how inbound email threading works in detail, or how an AI agent uses the whole loop.

Questions

Is there an email API that can send and receive email?

Yes. SendRaven sends transactional email and campaigns and receives replies on the same domain, joining each reply to the message it answers as a thread. GET /v1/threads?awaiting_reply=true returns every conversation that needs an answer.

How do I receive email replies through an API?

Publish the optional inbound MX record SendRaven returns when you add your domain. Replies to your messages then arrive as threads you can read with GET /v1/threads/{id}, and as an inbound webhook if you register an endpoint.

How are email replies matched to the original message?

By Message-ID. A reply echoes the original's Message-ID in its In-Reply-To or References header, and SendRaven looks that exact string up. It never falls back to matching the subject line, because that merges different customers' conversations.

Does receiving email cost extra?

No. Inbound email is included on every SendRaven plan, including Free, and received messages do not count toward the plan's emails.

Send a raven. Read what comes back.

3,000 emails a month free, inbound included, and never charged without an upgrade you choose.

Start freeThreads API reference