Integrates with everything. Works with nothing

The word "integrates" appears on every martech vendor's website. Integrates with Salesforce. Integrates with Marketo. Integrates with HubSpot. The logo wall on the integrations page shows twenty platform icons lined up neatly, implying that connecting the tool to your existing stack is straightforward, supported, and ready to go.

What "integrates" actually means varies so widely that the word has become almost meaningless.

For some vendors, it means a native, bidirectional, well-maintained connection that syncs data reliably between systems with minimal configuration. For others, it means a Zapier connector that someone built in an afternoon. For others, it means "we have an API and you can build whatever you need." For others, it means "we once had a customer who connected us to that platform and it worked for their use case."

The buyer sees the word "integrates" and assumes the connection is production-ready. The reality, discovered weeks into implementation, is that the integration requires custom development, ongoing maintenance, and compromises nobody mentioned during the sales process.

The integration gap between promise and reality

The gap between what vendors promise and what teams experience follows the same pattern regardless of the tool category.

The vendor demo shows data flowing seamlessly between the new tool and the existing platform. Contact records sync. Fields map cleanly. The data appears in the right places at the right time. It looks effortless.

The implementation tells a different story. The field mapping between the two systems isn't one-to-one. The new tool uses different field names, different data formats, and different object structures than the existing platform. Mapping them requires decisions about which system is authoritative for which data, how conflicts get resolved, and what happens when a field exists in one system but not the other.

The sync logic needs configuration. How often does data sync? In which direction? What triggers a sync? What happens when a sync fails? Are there rate limits? Does the integration handle bulk operations or only individual record updates? Each of these questions has an answer that affects how reliably the integration performs in production, and most of them aren't addressed until the team discovers problems after go-live.

The ongoing maintenance isn't mentioned at all. Both systems update regularly. Each update can change how the API works, which fields are available, and how data gets structured. An integration that works today can break after a platform update because a field was renamed, an endpoint was deprecated, or a data format changed. Somebody needs to monitor the integration, test it after updates, and fix it when it breaks. That somebody is usually the MOPs team, and the work wasn't in anyone's capacity plan.

What "integrates" should mean but usually doesn't

For an integration to be genuinely production-ready, it needs five things. Most vendor "integrations" provide one or two of them at best.

Bidirectional data flow. Data needs to move in both directions, from the new tool to the existing platform and back. Many integrations are one-directional: they push data in but can't pull data out, or they read from the existing platform but can't write back to it. A one-directional integration creates data silos where information gets trapped in one system without flowing to the others.

Field mapping that matches your data model. The integration should map to the fields your team actually uses, not to a generic default that requires manual adjustment. If your CRM uses "Company Revenue Band" and the new tool uses "Annual Revenue," someone needs to build the mapping and maintain it. The vendor's default mapping rarely matches any specific customer's data model without customization.

Error handling and monitoring. When a sync fails (and it will, eventually), the integration should log the error, alert someone, and provide enough information to diagnose the problem. Most lightweight integrations fail silently. Records stop syncing and nobody notices until someone compares data between systems weeks later and discovers a gap.

Performance at scale. An integration that works for 1,000 records may not work for 100,000. Rate limits, timeout thresholds, and processing queues all affect how the integration performs under real-world data volumes. Testing at scale before go-live is essential and rarely happens because the testing environment doesn't have production-level data volumes.

Maintenance support. When a platform update breaks the integration, who fixes it? If the answer is "your team," the integration isn't a managed connection. It's a custom build that you own and maintain indefinitely. The vendor's responsibility ends at providing the API. Everything built on top of that API is yours.

The hidden cost of "integrates"

The visible cost of a martech tool is the license fee. The hidden cost is the integration: building it, configuring it, mapping the data, testing it, monitoring it, fixing it when it breaks, and rebuilding it when a platform update changes the underlying architecture.

For lightweight tools with simple data flows, the integration cost may be minimal. For tools that sit at the centre of the stack and need to exchange data with multiple systems bidirectionally and in real-time, the integration cost often exceeds the licence fee over a three-year period.

Most teams don't account for this when evaluating tools because the vendor's "integrates with" claim implies the connection is simple and included. The cost appears later, distributed across the MOPs team's time: hours spent configuring the sync, troubleshooting failures, reconciling data discrepancies, and working around limitations that weren't disclosed during the evaluation.

If you're evaluating a new tool and the vendor says it integrates with your stack, ask five specific questions before signing anything. How does the data sync (API, webhook, middleware, native connector)? In which direction does data flow? What happens when a sync fails? Who is responsible for maintenance after platform updates? Can we see the integration working with a data volume comparable to ours?

The answers will tell you whether "integrates" means "production-ready" or "possible with significant effort." That distinction is worth tens of thousands in implementation and maintenance costs over the life of the tool.

Integration is an operational discipline, not a feature

The broader lesson is that integration between martech tools isn't a checkbox. It's an ongoing operational discipline that requires planning, configuration, monitoring, and maintenance for as long as the tools are in use.

The teams that treat integration as a feature (it was set up during implementation and should just work) end up with data silos, sync failures, and the slow drift of inconsistency between systems that undermines every campaign, every report, and every scoring decision built on top of the data.

The teams that treat integration as a discipline (someone owns it, monitors it, reviews it after updates, and fixes it when it breaks) maintain the data consistency that makes the rest of the marketing operation reliable.

Your martech stack is only as strong as the connections between the tools in it. And those connections need as much ongoing attention as the tools themselves. The word "integrates" on a vendor's website is the beginning of the conversation, not the end of it.