Email Is the API of Last Resort

Every system I end up building touches email eventually. Not because I like email—nobody likes email—but because email is the one integration layer that exists everywhere, whether a vendor planned for it or not.

When a platform hands you a real API, you use it. When it hands you nothing, it still hands you email. Order confirmations, sales notifications, receipts, alerts. That inbox is a message queue every company on earth already agreed to support.

The Vendor That Won't Give You an API

My card business sells across four marketplaces. Some have real APIs. One of them, Whatnot, tells you about a sale the same way it tells your aunt about a coupon: it sends an email.

So the inbox becomes the event source. When a sale confirmation lands, a job reads it, extracts what sold and for how much, and records it against the single source of truth—same as if a proper webhook had fired. The vendor thinks it sent a receipt. My system thinks it received an event. Both are right.

The important part is that I treat that email like a real integration, not a one-off script. Every message gets deduplicated so a re-send doesn't double-count a sale, and anything the parser can't understand gets set aside instead of silently dropped.

Reading Is the Hard Part

Parsing email sounds easy until you look at ten receipts from ten vendors. No two are formatted the same, and any of them can redesign their template on a Tuesday and break your regex without telling you.

So I stopped trying to write rules for every layout and let a model read the email the way a person would. Claude reads a receipt and pulls out the numbers I actually need—what the item was, what it cost, what the fees were—and feeds them into cost-basis accounting. When a vendor changes their format, nothing breaks, because I was never matching the format in the first place. I was reading the meaning.

Email Is Also an Output

The trick runs both directions. Email isn't just where messy data comes in—it's the most reliable place to put important data out, because it lands where people already look.

One of my systems reconciles a card shop's books overnight and then sends a single short email every morning: at most six sentences, each one a number that matters and why it surfaced. No dashboard to remember to open, no app to install. Just the six things worth knowing, in the inbox, before coffee.

My onboarding automation does the same on the human side—when a new hire is provisioned, the welcome email with everything they need goes out on its own. The work happened in a dozen systems. The proof shows up in one place the person already checks.

The Rules That Make It Work

Using email as an API is a little embarrassing and completely reliable, as long as you respect a few rules.

Deduplicate everything. Mail gets resent, forwarded, and delivered twice. Every inbound message needs a stable identity so the same sale never counts as two.

Fail quietly, alert rarely. My systems only email me about a problem after it fails twice in a row, so a transient blip never becomes a 2am notification. An inbox full of alerts you've learned to ignore is worse than no alerts at all.

Select, don't dump. The temptation with an outbound email is to include everything you know. Don't. The morning brief works because it's six sentences, not sixty. If a person has to scroll, you've already lost them.

The Duct Tape of Integration

None of this is elegant. There's no conference talk called "Email-Driven Architecture," and there never should be. But every business runs on email whether it has an API or not, which makes it the one integration that's already installed everywhere.

When a vendor gives you nothing, they've still given you an inbox. That's usually enough.