When a system a product depends on has no public API, the integration has to be built against whatever interface it does expose — even when that interface was designed for a human, not a program. On DinDin, a connected restaurant technology suite, that interface was an inbox.
01Reading the work
The problem: two marketplaces, no order API
DinDin's restaurant customers take orders from several channels — their own site, their point of sale, and third-party delivery marketplaces — and every one of those orders has to reach the same kitchen printer, the same reporting, and the same operational workflow. Grubhub and DoorDash orders were the gap: neither marketplace exposed the order API this workflow needed. What each marketplace does send, reliably, is an HTML order-confirmation email to the restaurant's own inbox — the same email a manager would read by hand.
02Reading the work
Building the integration against the inbox
The pipeline authenticates to that shared inbox and treats each incoming confirmation as the integration surface: it parses the HTML order-confirmation email, matches the merchant it belongs to, and extracts the order into DinDin's native order model. From there it is indistinguishable from an order taken on the restaurant's own site — it flows to the same kitchen printer and the same reporting. The Gmail API is a reasonable reference point for how an authenticated inbox integration like this is typically built (see: Gmail API guides, cited below).
03Reading the work
Deduplication: the part that makes it safe to re-run
An email-based integration has to tolerate being re-run — a connection can drop mid-fetch, or a message can get reprocessed. The pipeline deduplicates by each marketplace's own order number rather than deriving an identity from free-text content, so reprocessing the same confirmation email never creates a second kitchen ticket. This is the same idempotent-request discipline documented in payment-API design, where a client-supplied identifier is used specifically so a retried request cannot double-charge or double-create (see: Stripe's idempotent requests documentation, cited below).
04Reading the work
What this generalizes to
The general lesson is not specific to restaurants or email: when a system exposes no API, the integration is built against the most stable interface it does expose — even a human-facing one — and it is made safe to re-run with the same deduplication discipline a proper API integration would use. The inbox is not a workaround here; treated with the right discipline, it is the integration.
