Your iPaaS needs a B2B layer.

iPaaS emerged as a category in the early 2010s to solve a specific problem. The SaaS boom had produced hundreds of applications that every enterprise suddenly needed to connect to each other. Salesforce to NetSuite. Workday to ServiceNow. A procurement system to an ERP. The complexity was real and the tool that won the category solved it well.

The design of iPaaS assumed a set of things about the environment. The endpoints were modern SaaS APIs with documentation, probably REST, probably JSON. Authentication was OAuth or API keys. The data shapes were known and relatively stable. The consumer of the integration was a business process inside the enterprise. The trading partner was a colleague. The spec was a moving target but moved in predictable ways.

Every one of those assumptions holds inside the enterprise. That is why iPaaS platforms are legitimately excellent at what they were designed for. Wiring up Salesforce to NetSuite is a known problem with a known shape, and an iPaaS is probably the right tool for it. iPaaS platforms are not bad tools. They are good tools at the problem they were designed to solve.

None of those assumptions hold at the boundary between enterprises. The trading partner on the other end is not a colleague. The endpoint is not a SaaS API; it is an AS2 certificate exchange or an SFTP drop or a VAN interconnect. The authentication is mutual TLS and signed receipts. The data is X12 or EDIFACT, not JSON. The spec was last updated by someone who left two companies ago, communicated through an implementation-guide PDF attached to an email distribution list your team is not on. The consumer of the integration is an ecosystem of retailers, suppliers, marketplaces, and logistics providers whose compliance requirements change on annual cycles you are expected to track.

iPaaS platforms are weak at B2B for architectural reasons. The design assumptions that make them good at one problem make them structurally mismatched for the other. That is a different statement from saying iPaaS vendors are bad at their jobs. It is a statement about tools and the problems they were optimized to solve.

Most platform teams running on iPaaS discover the architectural mismatch on a specific day. It is usually a good day for the business, which is part of what makes it disorienting.

A new enterprise customer has signed. The partner list includes seven retailers, three 3PLs, a marketplace, and several distributors and manufacturers. 20 trading partners in total. The customer expects to be transacting within 30 days of signing. The contract reflects that expectation.

Day one of onboarding, the platform team opens the iPaaS to configure these partners. The EDI support is there but rudimentary. The X12 850 parser handles one common dialect well; three of the retailers on the list use variations the parser does not support. AS2 is an add-on with its own billing SKU and a configuration flow that was clearly built for one-off setups, not for a customer with 10 AS2 partners in their ramp. The certificate management is manual. The non-repudiation tracking is essentially absent. A spec bulletin from one of the retailers dropped last month; the iPaaS vendor has not incorporated it because their roadmap is focused on SaaS integration, which is what their other customers pay them for.

The platform team has two viable choices. Option one is to commission custom development from the iPaaS vendor, which turns into a multi-quarter engagement with custom pricing and a timeline that does not match the customer's 30-day onboarding window. Option two is to start building inside the iPaaS directly. Custom scripts. Custom connectors. Glue code that sits in the integration platform and handles what the platform was not designed to handle.

Neither choice is good, and both compound over time. The custom path turns the iPaaS into a shadow B2B platform, carrying work it was not designed to do, while also being worse at its original SaaS integration job because the team is split between two domains. The vendor-custom path makes the platform dependent on a vendor whose product roadmap is not aligned with the platform's actual workload. Usually the team ends up doing some of both, and the operational burden from both accumulates quarter over quarter.

The day the iPaaS hits the wall is not the day the team decides something went wrong. It is the day a senior engineer looks at the partner list from the next enterprise customer and realizes the same conversation is about to repeat itself, indefinitely, unless something changes structurally.

If iPaaS is the wrong tool for external B2B, what is the right tool? The answer is easier to see when the requirements are named rather than assumed.

A B2B infrastructure layer has to handle protocol coverage that extends beyond REST and JSON. AS2, AS4, SFTP, FTP, HTTP/HTTPS, X.400, VAN interconnects, and Peppol endpoints. None of these fit the SaaS API model. Some of them predate the SaaS API model by decades. All of them are still in active production use in significant portions of the trading partner ecosystem, and none of them can be dropped if the goal is to reach the partners your customers actually transact with.

It has to handle format transformation across standards that iPaaS tools treat as edge cases. X12 and EDIFACT in their primary and derived variants. Tradacoms. cXML. ebXML. VDA. The transformation problem is not "parse this format into JSON." It is multi-hop transformation across specs with conflicting interpretations, validation rules that change annually, and a requirement to produce output that a specific trading partner's implementation will accept without rejection.

It has to handle certificate and key management at scale that iPaaS tools do not contemplate. AS2 certificate rotation schedules across hundreds of partners. Public key infrastructure coordination with external organizations. Cert-pinning behaviors in partner firewalls that affect how new certs can be rolled out. Audit trails that satisfy compliance regimes years after the transaction.

It has to handle compliance enforcement as a first-class capability, not a reporting feature. Non-repudiation through signed MDNs and verifiable document archives. SLA tracking per partner. Retailer-specific validation rules that are updated on cycles the platform has to stay current with. Audit-ready logs that can be produced on request in formats external auditors recognize.

It has to handle operational intelligence at the network level, not the individual-transaction level. Anomaly detection across transaction patterns, not just threshold alerts on error counts. Mapping suggestions based on patterns across the ecosystem, not just the platform's own transaction history. Visibility that spans trading partner relationships, not isolated point-to-point integrations.

None of these are negotiable for a platform operating at production B2B scale. They are the baseline of the workload. A tool that treats any of them as an add-on is architecturally inadequate for the job, regardless of how good it is at something else.

The architectural resolution is not to replace the iPaaS. It is to add a layer alongside it. Internal integration, SaaS orchestration, API management, and developer experience for the platform engineering team stay on the iPaaS. External B2B connectivity, protocol coverage, format transformation, certificate management, compliance enforcement, and network intelligence move to a dedicated B2B infrastructure layer designed for that work.

The two layers connect through APIs. The iPaaS orchestrates workflows that cross both domains. The B2B layer handles the external connectivity primitives the iPaaS was not architected to handle. From the perspective of the platform's customer, there is one integration surface. Underneath that surface, two tools are doing the part of the job each is good at.

This is the same architectural move that has resolved other categories. CDNs did not replace web application servers; they added a layer in front. Payment processors did not replace checkout flows; they sat underneath as the infrastructure the flows depended on. Observability stacks did not replace the applications they monitored. In every case, the right answer was "two tools, each optimized for its layer," not "one tool trying to be good at everything."

B2B is arriving at the same answer. The platforms that are ahead of this have already separated the concerns. The platforms that are behind are stretching one tool across both problems and wondering why the one that matters most keeps underdelivering. The fix is structural, not incremental. No amount of customization closes the gap between an iPaaS and a dedicated B2B layer because the gap is in what the tools were designed to do.

A dedicated B2B infrastructure layer adds three categories of capability to the iPaaS stack. They are not features in a comparison matrix. They are architectural properties of a tool built for the workload.

Protocol and format coverage as core competency

The B2B layer handles the full protocol matrix (AS2, AS4, SFTP, FTP, HTTP/HTTPS, X.400, API, VAN interconnects, Peppol) and the full format matrix (X12, EDIFACT, Tradacoms, cXML, ebXML, JSON, XML, CSV, flat files, proprietary) as core capability, not as corner features of a broader product. The coverage keeps expanding because that is the business the tool is in. A partner that arrives with an unusual protocol requirement is handled, not deferred.

Network interconnection and partner coverage

The B2B layer provides interconnection to the broader B2B ecosystem. The public and private networks, the retailers, suppliers, marketplaces, and logistics providers your customers already transact with. A single integration with the B2B layer replaces hundreds of direct partner relationships. Every partner added to the network becomes available to every platform on the network. The partner coverage that would take a platform years to negotiate individually is inherited by joining.

Operational governance and shared intelligence

Certificate management, non-repudiation, compliance tracking, SLA enforcement, and anomaly detection happen at the network level. The operational overhead and the learned intelligence both scale across the network, not per-participant. Each platform that builds on top inherits capabilities that would take years to develop internally, and the capabilities continue to improve as the network carries more traffic, because the intelligence layer gets better with volume.

Each of these three is individually significant. Taken together, they are the difference between a tool that is adjacent to the problem and a tool that is designed for the problem.

The two-layer architecture is the right answer for a specific profile of platform. It is not universal. Being honest about when the single-layer approach is adequate helps distinguish the platforms this deep dive is actually for.

An iPaaS alone is enough if the external B2B requirement looks like SaaS integration. If the trading partners your platform reaches are modern SaaS endpoints with REST APIs and OAuth, an iPaaS will handle them well because those endpoints match the design assumptions the iPaaS was built around. The line is not "is there any external integration." It is "does the external integration look like SaaS integration or does it look like EDI-era trading-partner exchange."

An iPaaS alone is enough if the partner count stays small and the protocol mix stays narrow. If your platform reaches two modern retailers that both speak a current API protocol, the operational weight of a B2B layer is not justified. The B2B layer starts to pay for itself when the partner count crosses the threshold where protocol coverage, compliance tracking, and certificate management become full-time concerns on their own.

An iPaaS alone is enough if the compliance posture is permissive. If none of your customers require audit-ready non-repudiation, retailer-specific validation matrices updated on annual cycles, or SLA enforcement per trading partner, a platform can run without the compliance infrastructure a B2B layer provides. For most enterprise-selling platforms, that condition does not hold for long. Enterprise customers bring enterprise requirements.

The platforms this deep dive is for are the ones whose external B2B surface is expanding. Partner count is growing. Compliance requirements are tightening. Enterprise customers are arriving with requirements that their iPaaS was not designed to carry. For those platforms, the two-layer architecture is the correct answer. The question is which tool to put in each layer.

ECGrid is the dedicated B2B infrastructure layer this deep dive has been describing. 35-plus years in continuous production. API-first since ECGridOS shipped in 2013. More than 400,000 trading relationships and 300+ network interconnects already operational. Architected for platform tenancy, which means your platform builds on ECGrid rather than sending your customers to a separate interface to manage on their own.

The way ECGrid pairs with an existing iPaaS is clean. The iPaaS continues to handle SaaS application integration, internal workflow orchestration, API management, and the developer experience for the platform's engineering team. ECGrid handles trading partner networks, protocol coverage, format transformation, non-repudiation and compliance, certificate management, and the operational governance of the network layer. The two connect through APIs. The platform's customers see one integration surface.

What this does for an engineering team is specific. The iPaaS continues to serve its original purpose well because it is not being stretched. The B2B layer does what a B2B layer is supposed to do because it is designed for the workload. The custom code that was accumulating inside the iPaaS to handle EDI, AS2, and retailer compliance stops accumulating, because that work is now carried by the layer built for it. The team that was split across two domains is no longer split. The B2B operations that were eroding product velocity are handled at the network level instead.

For platform leaders evaluating this architecture, the reframe is straightforward. The conversation worth having is not "which vendor should we buy." It is "which layers does our platform need, and what is the right tool for each." Once the two-layer model is the agreed architecture, the vendor decisions in each layer follow naturally. ECGrid is the layer we operate. We have been running it for platforms to build on for more than 25 years. If your iPaaS is being asked to do things an iPaaS was not built to do, the answer is not a different iPaaS.

Tools are optimized for the problem they were designed to solve. Stretching one across a second problem produces worse outcomes on both.