// use case · inbound-parsing

Inbound email, parsed to JSON.

Give your product a real address that receives. Drin parses every inbound message — headers, text, HTML, attachments — into structured JSON and fires a signed inbound_received webhook in milliseconds. Threaded to the original, retained by plan, readable over the API or the dashboard.

Start free All use cases

Free sandbox to integrate · Production from $3/month

Blue duotone engraving: an incoming letter arriving at an open wall of labelled letterboxes, then passing through a tidy sorting mechanism that fans it out into neat labelled JSON cards — from, subject, body, attachments — each filed onto a threaded rail, an archive shelf behind it.

// the job

Email is a two-way street. Drin drives both.

Most senders treat receiving as an afterthought — a raw MIME blob dumped on a webhook that forgets after a month. Drin treats inbound as a first-class half of email: a real inbox on your own domain, not a black box.

Every message is parsed to clean JSON — from, subject, plain text, HTML, and attachments broken out — stitched into its thread by references, and kept for as long as your plan allows (7–180 days, longer on Enterprise). Get pinged by webhook, read it over the REST API, or hand it to an agent over MCP.

Real inboxes, your domainParsed to JSONThreaded + retainedAttachments broken out

#01 — How it works

A clean object, not a raw blob.

Subscribe your webhook to inbound_received and Drin does the MIME parsing for you — decoding, charset, attachments, threading — then posts a small signed event your handler can act on immediately, with the parsed body one API call away.

Read the docs →

inbound → your webhook

// POST → https://yourapp.com/inbound
{
  "type": "inbound_received",
  "data": {
    "from":        "sarah@gmail.com",
    "subject":     "Re: your invoice",
    "threadId":    "thr_2f9…",
    "messageId":   "msg_8c1…",
    "authResults": { "spf": "pass", "dkim": "pass", "dmarc": "pass" },
    "testMode":    false
  }
}

# text, HTML + attachments: GET /v1/emails/{messageId}/body · /attachments

#02 — What you get

The three that make it work.

DRIN · INBOUND & PARSING — WHAT YOU GETSHEET OF 3

01.1Structured, not raw

MIME parsed to JSON — from, subject, text, HTML and attachments broken out. Your handler acts on fields, not a raw payload.

01.2Threaded automatically

Replies are stitched to the original message by references, so a conversation stays a conversation across both directions.

01.3Retained by plan

Kept 7–180 days by tier (longer on Enterprise) and readable over the API — not a webhook that forgets after 30 days.

#03 — Built from

The surfaces that power it.

Not a bolt-on — this job runs on the same platform as everything else you send and receive. One account, one bill.

Receive →Send →Pricing →

#04 — Questions

Asked about inbound & parsing.

Do I get a real address or just a webhook?+

A real inbox on your own domain. Mail is stored, threaded and readable over the API or dashboard — the webhook is one way in, not the only record.

How is this different from Resend's inbound?+

Resend's inbound is a webhook with a 30-day retention ceiling. Drin gives you inboxes on your domain, parsed to JSON and retained by plan, that you can also read back over the API at any time.

Are attachments handled?+

Yes — attachments are parsed out of the message, stored, and downloadable over the API (GET /v1/emails/{id}/attachments); you're not left decoding MIME yourself.

Can an agent read the inbox?+

Yes. The same inbox is reachable over MCP, so an agent can read, search and reply on the thread.

Every job Drin is hired for →