Receiving email

Subscribe a webhook to email.received, and everything else follows from the payload it delivers.

// 1. verify the webhook, as with every Rasket event
const event = verifyWebhook(rawBody, headers, process.env.RASKET_WEBHOOK_SECRET);
if (event.type !== "email.received") return;

// 2. route on what the payload already carries — no call needed
const queue = event.data.received_for.includes("billing@inbound.acme.example")
  ? "billing"
  : "support";

// 3. read the parts the payload deliberately leaves out
const { data: message } = await rasket.emails.receiving.get(event.data.email_id);
const { data: files } = await rasket.emails.receiving.attachments.list(event.data.email_id);

// 4. each part carries a fresh signed link, good for fifteen minutes
for (const file of files.data) {
  if (file.download_url === undefined) continue; // a part we would not store
  await archive(file.filename, await fetch(file.download_url));
}

// 5. give the storage back
await rasket.emails.receiving.remove(event.data.email_id);

The same mail is waiting for you in the dashboard, under Inbox. Messages that answer each other are one conversation: we thread on the In-Reply-To and References headers a mail client sets, and never on the subject line, so two strangers who both write "Invoice" do not land in the same place. A message we accepted but would not store is threaded too, marked with the reason.

A conversation holds both halves — what arrived and what you sent back — and lives as long as the mail it is made of. Delete the last message and the conversation goes with it.

Only the screen was renamed. The API path /emails/receiving is unchanged, and so is every field on it.

You reply from the same name on your sending domain. A message to support@inbound.acme.example is answered as support@acme.example — the address the person already knows, and the one their mail client can line up with your DNS.

So replying needs a domain you have verified for sending. Your managed receiving address is ours rather than yours, and its reputation is shared, so it receives and never sends. A team that has verified nothing sees the composer switched off and Add a domain to reply in its place; the Domains reference is the path out of that.

The From picker offers any name you have saved at any of your verified sending domains, and nothing else — never an unverified domain, and never the managed address. Underneath it, Replies go to is shown rather than hidden, and you can point it at any address on a host you receive on: answer as sam@acme.example and keep the next message landing in support. An address we do not receive on is refused, because a reply-to nobody can answer is worse than none.

• One Re:, never a stack of them, and we set the headers that keep your answer inside the conversation on their side as well.
• Reply, or reply to everyone. Starting a new message, or forwarding one, is not something this release does.
• A reply carries no attachments. It is your text, your mailbox's signature if it has one, and the message you are answering, quoted.

If the domain you reply from does not receive mail and we have no arrival address to fall back on, the reply goes out with no separate replies-go-to at all — so the answer is sent to a domain we do not receive on, and you never see it. Turn receiving on for that domain.

The event carries the envelope and the attachment list, and nothing else. That is a decision rather than an omission, and each half of it has a reason worth knowing:

• No bodies. A webhook is retried until your endpoint accepts it. A body that was retried for six hours is six hours of duplicated content arriving at your endpoint, for a message you may not even want.
• No download links. A link lives fifteen minutes. One minted at delivery would be dead by the time a retry succeeded, which is a worse failure than no link at all — it looks like it should work.
• Enough to route. received_for, from, subject and the attachment list are all there, so the common case needs no call.

Route on received_for — the addresses of yours the message was accepted for — and not on to, which is whatever the sender wrote in the header.

Be reachable. There are two ways, and they differ only in which address people write to; everything downstream is identical.

• The address you already have. Every team is assigned a managed receiving address — anything@<word>.<our host> — on first visit to the Receiving screen. Anything before the @ reaches you, so you can tag threads without registering anything.
• Your own domain. Turn receiving on for a verified domain in an inbound-capable region and publish the one MX record we hand back. It sits at the inbound label unless you choose otherwise, so anything@inbound.acme.example lands in the same place. Set receiving_host to another label, or to @ for anything@acme.example itself — but an MX at @ takes the domain's mail from whichever mailbox provider has it today, so choose it only for a domain whose every address should reach us.

Receiving is available in two regions. A verified domain outside them cannot receive at all, and its domain page says so in place of an address rather than offering a toggle that would do nothing.

A message larger than 150 KB, attachments included, never enters the loop: the sending server is refused before the message reaches us, so there is no event and no record. We do not hold it, and we do not truncate it.

A message we accepted but would not store is still recorded, with its bodies null and no attachments, so that "nothing arrived" and "something arrived and we would not keep it" are never the same silence.

Your mail is kept until the mailbox is full. There is no retention window on a message you keep: it stays until you delete it. What bounds it is an allowance in bytes, and a daily message cap alongside it. With the mailbox full, the next message is recorded with a dropped_reason rather than stored — never an older one thrown away — so the loop keeps running and you find out from the payload.

Another 100 GB is $15 a month on any plan, the free one included. Buy it from Inbox in the dashboard; it is billed on your subscription and the allowance applies at once.

DELETE /emails/receiving/{email_id} is how the room comes back. It removes the stored objects as well as the record and returns the bytes to your allowance; there is no undo and no soft delete. A dropped record is the one thing that does age out, on your plan's data retention window — and like a deleted message it goes whole, so it answers 404 rather than coming back with an empty body.

An email you send over the API can be answered in the Inbox like any other conversation. Set reply_to to a name at an address you receive on, and the answer arrives somewhere we can see it.

Arriving is all reply_to does. What puts the answer on the right conversation is the In-Reply-To it carries, pointing back at the message you sent — so a reply_to at an address we do not receive on threads nothing, because the answer never reaches us at all.

A reply is an email. It goes out through the pipeline POST /emails uses, on the transactional meter, and counts as one message on your plan: a thousand replies are a thousand emails.

There is one edge worth knowing before you meet it: a reply whose every recipient is on your suppression list is refused after the message has been counted. The composer checks suppression before it lets you type, so this only happens to an address suppressed in the seconds between.

What you have sent and what your plan allows are on the dashboard's Usage screen, beside every other send.

• The Receiving reference — all seven operations, with the shape of every response.
• Events — the email.received payload in full, beside every other event.
• Domains — turning receiving on, and verifying the sending domain a reply needs.