Email Integration Tools: Connecting Your Marketing Stack
Native integrations, middleware and custom work — with the failure mode each one has when data stops flowing.
On this page
The short version
- Three ways to connect systems — native, middleware, custom — and each fails silently in a different way.
- The failure that matters is not an error, it is a sync that stops and reports nothing. Every integration needs a check that it is still running.
- Match on a normalised email address and measure the match rate, or a join failing on a fifth of records will look like a fifth of customers who never bought.
An email programme of any size ends up connected to something: a commerce platform, a CRM, a support desk, a data warehouse. How those connections are made determines what breaks and how you find out.
All three approaches work. What differs is the failure mode, and in every case the failure is quiet — data stops flowing, nothing errors, and the symptom appears weeks later as a segment that has stopped growing.
Three approaches
| Approach | Suits | Fails by | Cost |
|---|---|---|---|
| Native integration | Common pairs of tools | Silently, after a vendor update | Included |
| Middleware | Many tools, simple mappings | Silently, when a plan limit is hit | Per operation |
| Custom | Anything specific | Silently, when a token expires | Build and maintain |
Native first, and check what it actually syncs
A native integration between two products is the cheapest and most reliable option when it exists, because the vendors maintain it.
The thing to verify is scope. "Integrates with" can mean anything from full bidirectional sync of every field to a one-way push of email addresses on a nightly schedule. The difference decides whether you can build the segments you wanted.
Check three specifics: which fields sync, in which direction, and how often. A nightly one-way push of addresses is a different product from a real-time sync of purchase events, and both are described the same way in a directory listing.
The join, again
Almost every integration matches on email address, and almost every one of them fails on some fraction of records: guest checkouts with a different address, plus-tagged variants, case differences, typos.
Normalise on both sides before matching — trim, lowercase, and a stated policy on plus-tags — and then measure the match rate. An unmeasured join failing on a fifth of customers will understate email's contribution indefinitely and look exactly like a fifth of customers who never bought.
Where a person genuinely has two addresses, the honest answer is two records with acquisition messaging suppressed for both, rather than an automatic merge that guesses.
Middleware, and its specific trap
Middleware — the connector services that link tools without code — is excellent for simple mappings and has one characteristic problem: it is priced per operation, so a busy month can hit a plan limit and stop.
When that happens the sync does not error in a way anyone sees; it queues or drops, and the alert lands in the inbox of whoever set up the account, who may not work there any more.
Two mitigations. Put the account alerts on a shared address, and include the middleware in the same heartbeat check as everything else. The tool's own monitoring is not a substitute for your own, because the failure you care about is the one where the tool itself has stopped.
Custom, and what it commits you to
A custom integration is the right answer when nothing else expresses what you need, and it is a permanent maintenance obligation — API versions are retired, tokens expire, schemas change.
The two things that make one survivable: it logs what it did, and it fails loudly. An integration that writes a line per run and alerts on an empty run is one somebody can debug two years later; one that runs silently is one nobody can.
Also write down what it does, in a place that is not the code. The person who needs that document will be someone who has never seen the codebase.
Integration check
- Native is used where it exists and covers what you need
- Which fields, which direction and how often are all confirmed
- The email join is normalised on both sides
- The match rate is measured, not assumed
- A heartbeat alerts when a sync produces nothing
- Middleware account alerts go to a shared address
- Custom integrations log every run and fail loudly
- What each integration does is documented outside the code
Frequently asked questions
How do I know an integration has stopped?
You will not, unless something checks. Alert on the count of records synced falling to zero, or on the newest record being older than a threshold — those are the only signals most integrations produce.
Is real-time sync necessary?
For suppression, yes — selling someone what they bought an hour ago is the error readers notice most. For reporting and segmentation, a daily batch is usually adequate and much simpler.
What happens to integrations during a platform migration?
They all have to be rebuilt, and that is frequently the largest part of the work. Inventory them before choosing a new platform, because an integration that exists natively on one and requires custom work on another is a real cost difference.