DEV Community: Yaobuilds

Turn any newsletter into a database

Yaobuilds — Wed, 05 Aug 2026 21:25:50 +0000

Newsletters are the strangest data feed on the internet. Airlines, deal hunters, job boards, real estate brokers, security teams: thousands of organizations run pipelines that end in a beautifully formatted email, and nowhere else. There is no API. There is no RSS. There is a designer-approved HTML table in your inbox, and that is the product.

Which means your inbox is quietly one of the best free data sources you have. You just cannot query it.

This tutorial fixes that. By the end, a flight-deals newsletter will be landing in a Postgres-queryable event stream as typed JSON, and the whole thing takes about fifteen minutes. Disclosure up front: I built the service used in the middle step (Inbin), after running the DIY version inside my own product first. The pattern works with any extraction layer, including one you build yourself.

The architecture

Newsletter (Going, TLDR, anything)
        ↓  subscribes to
inbox address (yours-a3f2c8@in.inbin.dev)
        ↓  extraction against your schema
typed JSON event
        ↓  HMAC-signed webhook
your app / database

The trick is the middle: instead of your personal email address, you subscribe the newsletter to a machine address, and every edition that arrives is parsed against a schema you declare once.

Step 1: create an inbox

import { Inbin } from "@inbin/core";

const inbin = new Inbin({ apiKey: process.env.INBIN_API_KEY });

const inbox = await inbin.inboxes.create({ name: "flight-deals" });
console.log(inbox.address);
// flight-deals-a3f2c8@in.inbin.dev

That address is permanent. It is also receive-only, which matters: the worst a leaked newsletter subscription can do is send you more newsletters.

Step 2: declare what every edition should become

This is the part that replaces the parser you would otherwise write. Describe the fields; do not describe how to find them.

await inbin.schemas.put({
  extract: {
    deals: {
      type: "array",
      items: {
        destination_city: { type: "string", required: true },
        origin_iata: { type: "string" },
        price_usd: { type: "number", required: true },
        airline: { type: "string" },
        travel_window: { type: "string" },
      },
    },
  },
  hallucination_guard: true,
});

Two design notes:

Arrays are the right default for newsletters. One edition usually carries many records (five deals, ten stories, three listings). Declaring deals as an array means one email becomes five rows, not one blob.

Turn the hallucination guard on. Extraction here is LLM-based, and language models will confidently invent a price if you let them. The guard checks that every extracted string appears verbatim in the source email, and every number in its digits; anything it cannot back comes back null. Missing data is recoverable. Invented data is poison in a database.

Step 3: subscribe the newsletter

Go to the newsletter's signup page and enter the inbox address. That is the whole step. Some senders require confirming the subscription; the confirmation email also arrives as an event, so you can grab the confirm link from your dashboard or the API.

Step 4: receive rows, not emails

Point your webhook at an endpoint and verify the signature against the raw body:

import { verifyWebhook } from "@inbin/core";

export async function POST(request) {
  const raw = await request.text();
  const event = verifyWebhook(
    raw,
    request.headers,
    process.env.INBIN_WEBHOOK_SECRET,
  );

  for (const deal of event.extracted.deals ?? []) {
    await sql`
      INSERT INTO deals (city, price_usd, airline, received_at)
      VALUES (${deal.destination_city}, ${deal.price_usd},
              ${deal.airline}, ${event.received_at})
    `;
  }
  return new Response("ok");
}

Every edition of the newsletter now becomes rows in your table, minutes after it is sent.

Step 5: skip the table entirely (optional)

If you do not want to run a database for this, the events are already queryable where they land:

curl -X POST https://api.inbin.dev/v1/query \
  -H "Authorization: Bearer $INBIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "flatten": "deals",
    "where": [{ "field": "price_usd", "op": "lt", "value": 300 }],
    "group_by": "destination_city",
    "aggregate": [{ "fn": "avg", "field": "price_usd", "as": "avg_price" }]
  }'

{ "rows": [ { "destination_city": "Lisbon", "avg_price": 274.5 } ] }

Filter, sort, group, aggregate: the inbox is the database.

What people actually build with this

Price watchers: alert when any deal to a saved city drops under a threshold.
A personal news API: three newsletters in, one deduplicated JSON feed out.
Market history: newsletters are ephemeral; a table of every deal ever sent is not. Six months of data tells you what a genuinely good price looks like.
Agent food: the same events are exposed over MCP, so an AI agent can query them natively. That one gets its own article.

The general lesson holds beyond newsletters: any email your business receives on a schedule (invoices, shipping updates, alerts) is a feed pretending to be correspondence. Declare a schema and it stops pretending.

If you want to try the hosted version, it is free while in beta at inbin.dev.

SES vs Mailgun vs SendGrid vs Postmark: inbound email compared

Yaobuilds — Sat, 25 Jul 2026 16:47:58 +0000

Four services will accept email for your domain and call your webhook. They differ in one dimension that matters more than any pricing table: how much of the message they digest before it reaches you, and how much is still your problem.

The one-table version

Service	Your endpoint receives	MIME parsing	Webhook authentication
AWS SES	Raw MIME (usually via S3 + Lambda/SNS)	None, you parse	Standard AWS auth (IAM, SNS signatures)
Mailgun Routes	Form fields (subject, body-plain, stripped-text...)	Yes	HMAC signature on each POST
SendGrid Inbound Parse	Multipart form fields, optional raw MIME	Yes (basic)	None built in, secure the URL yourself
Postmark Inbound	One clean JSON object	Yes, the most complete	Basic auth / restrict by IP

AWS SES: the raw pipe

SES receiving is rule-based: mail for your domain matches a receipt rule, and the rule delivers the raw message to S3, invokes a Lambda, or publishes to SNS. What lands is the complete, unparsed MIME document. SES attaches spam and virus verdicts plus SPF/DKIM results, which is genuinely useful, but the message itself is yours to decode: multipart trees, base64 bodies, encoded headers, attachments.

Choose SES when you are already deep in AWS, want the lowest per-message cost at volume, and are comfortable owning a parsing layer (in practice: a Lambda wrapping a MIME library, plus the maintenance that follows). Note that inbound is supported in fewer regions than outbound, so check yours first.

Mailgun Routes: pattern matching plus parsing

Mailgun's inbound story is routes: expressions matched against the recipient (match_recipient, catch-all patterns), with actions like forwarding to a URL. The POST your server gets is already parsed: subject, sender, body-plain, body-html, and the handy stripped-text (the message minus quoted replies and signatures). Each POST carries an HMAC signature you verify with your signing key.

Choose Mailgun when you want flexible recipient routing (many addresses, one domain, different endpoints) and are fine with form-encoded payloads. The parsing is solid; the data is still email-shaped, not application-shaped.

SendGrid Inbound Parse: the veteran

Point MX records at mx.sendgrid.net, register a hostname and URL, and SendGrid POSTs each message as a multipart form: headers, text, HTML, attachments, plus SPF results and a spam score. A checkbox switches to raw MIME delivery if you would rather parse yourself.

The sharp edge: inbound parse POSTs are not signed. The standard mitigations are an unguessable URL, basic auth embedded in it, or an allowlist, all of which are on you. It works, it has worked for a decade, but the DX shows its age.

Postmark Inbound: the best mail-pipe DX

Postmark gives you an inbound address (and optionally your own domain) and delivers each message to your webhook as a single JSON document: sender, recipients, subject, TextBody, HtmlBody, headers, and attachments as base64. Of the four, it is the one where you can go from zero to a working handler in an afternoon without reading a MIME RFC.

Choose Postmark when developer experience matters more than squeezing cost at volume and you want JSON rather than form fields.

The step none of them do

All four stop at the same line: they hand you the email. If your application needs the data inside it, the vendor invoice total, the listing price, the deal in a newsletter, you are writing the extraction layer yourself: regex against text bodies, DOM scraping against HTML, and a quiet breakage every time a sender redesigns their template. That layer is where inbound email projects actually rot.

Full disclosure: that layer is the product I build. Inbin sits where your webhook handler would: you declare a schema (the fields you want), point any of your email at an inbox address, and receive typed JSON with a guard that drops any value the extractor cannot find literally in the source email. If you already run SES or Mailgun happily and your parsing is stable, you do not need it. If you are about to write the third regex for the same newsletter, you might.

Which one should you pick?

Already on AWS, high volume, own the parsing: SES.
Many addresses routed to different endpoints: Mailgun.
Already a SendGrid customer for outbound: Inbound Parse is fine; secure the URL.
Fastest path to a clean JSON webhook: Postmark.
You want the data, not the email: an extraction layer, ours or your own.

Mechanics above reflect each provider's documented behavior at the time of writing; pricing changes often enough that I deliberately left it out. Corrections welcome.