API-to-API Integration Without Custom Middleware

None of these variables works in isolation. Run them together, weigh them against your actual constraints (not your hoped-for ones), and the right pattern usually declares itself. If it doesn't, that's a sign you need a pilot, not a spreadsheet.

How much integration complexity teams are actually dealing with in 2025

Large enterprises (10,000-plus employees) run an average of 660 apps, according to Zylo's 2025 report. Zylo's 2026 numbers put the average company, across all sizes, at 305 SaaS applications. At that scale, hand-coding a connection for every pair of systems isn't just tedious. It's arithmetic working against you: add one more app to a hand-wired mesh and you've added dozens of new connection points, not one.

APIs stopped being optional a while back, too. Postman's 2024 State of the API Report found over 83% of enterprise workloads depend on APIs for data communication and automation. That's the plumbing now, the way electricity is structural to a building rather than something you bolt on after the walls go up.

The market noticed, predictably. Gartner tracked iPaaS revenue crossing $9 billion in 2024, up from $5.9 billion in 2022. Roughly doubling in two years is not the growth curve of a quiet niche category. ONEiO's May 2025 research counted over 900 integration software solutions on the market, with around 270 of those being dedicated iPaaS platforms. Back in 2018 there were 47 iPaaS vendors, total. Now it's 300-plus, all fighting for the same slide in the same sales deck.

Picking an integration approach in 2025 isn't purely a technical decision anymore. It's a shopping problem, and a crowded one at that.

The four patterns for connecting APIs without building custom middleware

An API is a callable interface, something that exposes data or lets you trigger an action somewhere else. Middleware is the layer that translates between two APIs so they can actually talk. "No custom middleware" doesn't mean nobody handles auth tokens, retries, and schema mismatches. It means a platform does that work instead of an engineer hand-coding it the night before a launch.

Four patterns cover almost everything teams actually do. Each trades speed for control, or control for speed, in a slightly different way.

Direct point-to-point integration. One system calls another's API directly, no middle layer. Each connection owns its own auth, pagination, error handling, schema mapping, the works. Great for a handful of critical, high-volume connections where you want full control. Ugly fast once you're past a few, because maintenance load multiplies with every API you bolt on.

iPaaS platforms. Low-code or no-code tools with pre-built connectors and visual workflow builders, covering API-centric, data-centric, event-driven, and app-centric integration in one place. The platform absorbs the orchestration work a middleware layer used to require by hand.

Unified API platforms. Build one normalized API instead of fifteen separate CRM integrations. One build, many connectors unlocked. Common in SaaS products where integrations are a customer-facing feature rather than internal plumbing.

API gateways and marketplaces. A layer in front of third-party APIs handling security, rate limiting, and routing centrally, instead of scattering that logic through your application code.

None of these four wins by default. They fit different team sizes, volumes, and growth curves, and the gap between them is worth walking through one at a time.

When direct API-to-API connections outperform managed platforms

Going direct has one obvious selling point: no platform ceiling, no platform pricing tier, no platform-shaped delay between you and the data.

Practitioner testing in 2025 backed that up with real numbers. Zapier failed outright at 50,000 records a day. Make handled 100,000, then started timing out. Workato scaled further, but the bill climbed past $4,000 a month to get there. A direct HubSpot-to-Salesforce integration, built with custom API calls and nothing in between, handled 500,000 records daily without complaint. Cost: sixty hours of senior engineering time upfront, $150 a month after that.

That's performance. Cost flips the story, and faster than most teams expect. Zapier at $50 a month looks cheap next to a $3,000 custom build, at first glance. Run it two years out, though, and the custom build settles at roughly $1,800 a year in flat hosting, while the iPaaS subscription runs $600 to $2,400 a year and keeps climbing as usage climbs. Somewhere in year one or two, direct integration stops being the expensive option.

It earns its keep with a small number of high-volume, business-critical connections, senior engineers who can build and own the thing long-term, and APIs on both ends that don't rewrite their schema every quarter.

It falls apart the moment you need many connections. Every new API brings its own auth scheme, its own pagination quirks, its own error codes to memorize. A provider changes their API without warning, and that's now your team's problem, on their timeline, not yours. Supporting fifteen different CRM providers this way isn't a shortcut. It's a full-time job for somebody.

What iPaaS platforms actually provide and where they create new problems

iPaaS exists to replace the orchestration work custom middleware used to demand. A mature platform gives you pre-built connectors across hundreds of apps, data mapping and transformation tools, workflow orchestration, event-driven triggers, and a visual builder a business analyst can use without knowing what a webhook is.

The big names each lean into a different pitch. MuleSoft's Anypoint Platform covers the full API lifecycle, design through monitoring, and added MCP support plus Einstein-driven generative flows this year. Workato scales at enterprise volume and launched Workato One in 2025, bundling Agent Studio, Agent Trust, and AgentX Apps, along with PCI DSS 4.0-level security. Zapier and Make sit at the accessible end, fine for lower-volume work, though you already saw where their ceilings sit.

Low-code interfaces roughly triple the number of people inside a company who can build an integration flow. Sounds great until you remember that a business analyst shipping a workflow without engineering review is also a business analyst who can accidentally sync sensitive customer data somewhere it shouldn't go. Speed for the business user costs control for whoever's supposed to be watching data security and system reliability, and that tension doesn't resolve on its own. Somebody has to manage it, actively, on purpose.

Connector quality is the quieter limitation. A pre-built connector is only as current as whatever the vendor decided to prioritize that quarter. A SaaS provider ships a new feature your workflow needs, and you wait for the vendor to update their connector, if they ever do. Quality isn't uniform across the industry, either. Some connectors get real maintenance; some are clearly an afterthought somebody built once and forgot.

Gartner projected in 2023 that 65.9% of enterprises would use iPaaS by 2025. Wide adoption, sure. That doesn't make it the right fit for whatever integration you're staring at right now.

How unified APIs handle integration across an entire category of providers

The pitch: build one integration, get every provider in a category. All CRMs. All HRIS platforms. All accounting systems. A normalized data model sits on top, and your code talks to that model instead of fifteen vendor APIs with fifteen separate quirks.

Two architectures dominate, and they trade off differently. One model operates as a real-time proxy: it takes a request, translates it, forwards it to the actual provider, normalizes the response on the way back, and stores nothing but tokens and logs. The other model pulls data ahead of time and stores it, so reads are fast but occasionally a little stale.

The vendor field has actual personalities, which helps. Nango supports over 800 APIs and suits engineering-heavy teams chasing maximum connector coverage and full control over the wiring. Merge targets enterprises focused on HR, accounting, and CRM. Apideck runs the real-time proxy model and continues to develop its platform. Unified.to is another player in the space with its own architectural approach. Paragon targets B2B SaaS teams.

That last detail points at something bigger happening across the category: The intersection of unified APIs and AI agents is an active area of development across the category.

The cost math favors unified APIs specifically when breadth is the goal. A custom connector takes meaningful engineering time to build, plus upkeep after. Do that math on five integrations and you're burning ten to twenty weeks of engineering time before shipping a single feature your customers actually asked for. A unified API turns that upfront time cost into a recurring subscription instead. Good trade if you need broad category coverage, bad trade if you only need one deep, high-volume connection.

There's a real cost to the normalization, too. Customization is capped at whatever the unified schema supports, and if a provider's API does something outside that schema, you're stuck. And "unified" is the vendor's model, not an industry standard, so leaving one later means real lock-in risk, not a quick swap.

The practical variables that determine which pattern fits a given situation

No pattern wins in every scenario. The right one falls out of a handful of variables that interact with each other more than any single one decides things alone.

Start with how many integrations you actually need. A small number of high-volume, stable connections favors direct integration, usually the cheaper option once you look past year one. Many integrations within a single category, every major CRM or every HRIS platform, points straight at unified APIs. Wide orchestration across many unrelated systems is iPaaS territory, full stop.

Then there's who's building the thing. Senior engineers with time to spare can own direct integrations long-term without much drama. A mixed team that includes business analysts or product managers who need to build flows themselves calls for iPaaS, paired with real governance rather than good intentions. A small engineering team shipping integrations as a product feature should lean unified API, so nobody's maintaining a connector per provider forever.

Volume and latency matter, too. Very high daily record counts with zero tolerance for throttling rule out most managed platforms; Zapier and Make both hit documented ceilings well below where direct integration starts to strain. Standard SaaS-level volume with some flexibility on timing works fine on iPaaS or unified APIs. Real-time reads paired with data privacy requirements push toward the proxy model over the cache model, since one stores nothing and the other trades freshness for speed.

API stability on both ends changes the risk profile substantially. Stable, versioned APIs that rarely touch their schema make direct integration a low long-term maintenance risk. Fast-moving providers who ship constantly turn connector lag into a real operational headache on iPaaS, and unified APIs at least spread that risk across the vendor instead of dumping it all on your team.

Time-to-market pressure tips the scale hard. Direct integration front-loads its cost; that sixty-hour build doesn't happen overnight. Managed platforms and unified APIs get you to a working integration faster, because you're trading engineering hours for a subscription line item.

Governance requirements, especially in regulated industries, change which trade-offs are even acceptable. A platform that lets any business analyst spin up a flow touching customer financial data isn't a convenience in that context. It's a liability waiting for an audit to find it.