Email is the one integration every organization already has. Suppliers send invoices to it, forms deliver submissions to it, machines emit alerts to it. Email ingest treats that as an interface rather than a chore: a script connects to a mailbox, reads what arrived, and does something with it.
It's an old pattern and an underrated one, because the alternative — asking every counterparty to adopt your API — usually isn't available. This page covers what it's good for, how to build it so it doesn't break, and where a webhook is genuinely the better answer.
What Email Ingest Over IMAP Is For
Email ingest earns its place wherever the sender won't or can't integrate with you directly.
Documents from counterparties. Invoices, purchase orders, delivery notes and statements arrive as attachments from organizations who will never build against your system. A script that files them by sender and reference is often the entire integration.
Alerts from equipment. Plenty of hardware sends email and nothing else — backup appliances, monitoring systems, older industrial equipment. Email ingest over IMAP gives all of it a single collection point.
Form submissions and replies. Anything that emails you a structured message, including bounce notifications and out-of-office replies you want to act on.
Approvals by reply. A person replying "yes" to a message is a workflow step, and reading that reply programmatically is frequently simpler than building an interface nobody wants to log into.
Setting It Up So It Doesn't Break
The mechanics of email ingest are unremarkable; the durability comes from a handful of decisions.
Give it its own mailbox. Not a folder inside somebody's, and not shared with a human reading the same messages. A dedicated address means the script's assumptions can't be broken by a person tidying up, and it costs nothing here because mailboxes aren't billed per seat.
Use a credential scoped to the job. Not somebody's login. If the script's credential leaks or needs rotating, that should affect the script and nothing else.
Move processed messages, don't delete them. A "processed" folder gives you an audit trail and a way to reprocess after a bug. Deletion makes every mistake permanent, and there will be mistakes.
Handle the same message arriving twice. Retries, reconnections and reprocessing all happen. Keying on the Message-ID and skipping anything already seen turns duplicate processing from a data problem into a no-op.
Fail loudly. A script that stops reading a mailbox is invisible until somebody asks where the invoices went. It should complain when it hasn't run, not only when it errors.
Why IMAP Suits This
Email ingest works over IMAP because IMAP is a genuine remote filesystem for mail rather than a download protocol.
You can search server-side, fetch only headers before deciding whether to pull a body, move messages between folders, and set flags — all without downloading a mailbox. That means a script can be selective and cheap, which matters when the mailbox has years of history in it.
It's also universally supported, which is the real argument. Every language has a library, the protocol hasn't changed in ways that break things, and a script written today will still work in a decade. That's a stronger guarantee than most vendor APIs offer.
Worth knowing: the free plan includes IMAP, so a receiving-only ingest mailbox costs nothing at all. What it can't do is send, so anything that replies programmatically needs a paid plan or its own SMTP profile.
The Cost of Running It
The cost side is usually the surprise, because it's smaller than people assume.
An ingest mailbox is an ordinary mailbox, and mailboxes are capped by plan tier rather than billed individually. So the marginal cost of adding a twelfth ingest address is nothing, which is what makes one-mailbox-per-source practical rather than extravagant. What you're actually spending is storage from the shared pool, and attention when something breaks.
That changes the design calculus compared with platforms charging per seat. There, email ingest tends to get crammed into one overloaded address because each new one costs money, and the resulting script has to disentangle several unrelated streams. Here the cheap option is also the clean one.
Where a Webhook Is Better
Being clear about this saves people from building the wrong thing.
If the counterparty offers a webhook, take it. Push beats polling on latency, reliability and clarity: you get a structured payload the moment something happens, rather than discovering it on your next poll and parsing prose. Email ingest is the fallback for when no such option exists.
Polling also has a floor. Checking every minute is fine; checking every second is abusive and will be rate-limited. If your requirement is genuinely real-time, email is the wrong transport regardless of how you read it.
And parsing human-written email is a losing game. Extracting a purchase order number from a machine-generated message is reliable; extracting intent from a paragraph a person typed is not, and building a workflow that depends on it will produce a steady trickle of failures nobody can fix.
Scaling Past One Mailbox
Email ingest generalizes well, and the shape it takes depends on how many streams you have.
For a handful of sources, one mailbox per source is clearest — each script reads its own address, and a change to one can't affect another. Since mailboxes are capped by tier rather than charged individually, twenty ingest addresses cost the same as one.
For many sources of the same kind, a single mailbox with a catch-all in front works better: invoice-acme@, invoice-globex@ all land in one place, and the address itself carries the routing information the script needs. That's the same technique as an alias per signup, used for machines instead of vendors.
Where the volume is genuinely large, remember that the storage pool is shared. An ingest mailbox accumulating attachments will consume it, so a quota and a retention policy belong in the design rather than being discovered later — covered in mailbox storage quotas.
