Cross-source deal comparator.Cross-source deal comparator.Cross-source deal comparator.Cross-source deal comparator.

The deals you actually want to see are the ones that appear in only one of the five newsletters you get. Aggregation solves the reading problem, comparison solves the buying one.

One inbox on Inbin, 4 newsletter or alert subscriptions pointed at it. Every email that lands gets parsed against your schema.

One PUT to /v1/schemas. Inbin extracts these fields from every future email. Hallucination guard drops anything the model invented.

{
  "extract": {
    "offers": {
      "type": "array",
      "items": {
        "merchant":     { "type": "string", "required": true },
        "item":         { "type": "string", "required": true },
        "discount":     { "type": "string" },
        "sale_price":   { "type": "number", "nullable": true },
        "expires_at":   { "type": "string", "nullable": true },
        "source":       { "type": "string", "required": true }
      }
    }
  }
}

1. 01
   Create the inbox

   POST /v1/inboxes returns a permanent forwarding address like abc123@in.inbin.dev. Use it everywhere you subscribe.
2. 02
   Point the sources at it

   Enter that address directly in each source’s notification settings or signup form (Uber Eats, DoorDash, etc.). If a source sends a verification email, Inbin detects it and shows you the link or code to confirm. For mail that only goes to your own mailbox, a Gmail forwarding filter works as the fallback.
3. 03
   Declare the schema

   Paste the JSON above. Inbin creates version 1 and tracks every future version; any event can be re-extracted against the new shape with one call.
4. 04
   Consume the events

   Every parsed email hits your webhook as HMAC-signed JSON. Or read them via GET /v1/events. Or query them from an agent via MCP.

vs. Manual: check 4 apps every time.

Every product listed above exists because the underlying data was hard to get. Newsletters give you that data for free. Inbin structures it.

Also worth building