Why companies choose direct API connections
The reasoning is understandable. A middleware platform like MuleSoft or Azure Integration Services comes with licensing costs, a learning curve, and an additional management layer. If you want to connect two or three systems, that feels like paying upfront for complexity you do not yet have. A direct REST connection between your WMS and your transport partner seems like the pragmatic path. You build an endpoint, write a small service that forwards messages, and you are in production before the end of the quarter. That works. Until it does not.
Pitfall 1: error handling without a safety net
In point-to-point integrations, error handling is the responsibility of the connection itself. There is no central broker to catch messages when an endpoint is temporarily unreachable. In practice, this means a timeout on the receiving end causes a message to silently disappear, unless you have built in retry logic, dead-letter queues, and alerting yourself. That is exactly the work middleware does for you. Without that foundation, teams often build something half-hearted: a log table in the database, a daily manual check, or simply the assumption that both sides are always available. On a busy operational day, when a supplier API schedules a maintenance window that was never communicated, the gaps become visible.
Pitfall 2: endpoint version management
External systems update their APIs. Sometimes with a version number in the path, sometimes not. If you have built five direct connections to five suppliers or partners and three of them release an API update in the same quarter, you have three separate projects to update. Without a middleware platform, you have no adapter layer that centralises the translation. Each connection is its own codebase with its own assumptions about the data format. With a small landscape of two or three connections, that is manageable. With ten or more, it becomes a quiet form of technical debt: the integrations run, but nobody knows exactly which versions of which endpoints are in use, and supplier updates are addressed reactively rather than planned.
Pitfall 3: monitoring without a central layer
Middleware platforms provide a dashboard by default: message volume, latency, error rates, per connection. Without such a platform, you have to build that observability yourself or go without it. What we see in practice: the first connections get logging, the third and fourth somewhat less, the fifth almost none because the project was under pressure. The result is that operationally you only discover a connection has gone silent when someone on the other end calls. Proactive monitoring, alerts for stalled message flows or unusual volumes, requires discipline and build time that is structurally underestimated in direct connections.
When building integrations without middleware is actually the smart choice
To be fair: there are good reasons not to use a middleware platform. If your landscape is small and stable, say two or three connections with systems whose APIs are mature and well documented, a platform adds cost and management overhead without proportional value. If the connection is internal, between systems you manage and version yourself, you do not need a central broker either. And if you are building a greenfield system where the architecture is API-native from the start, you can place integration responsibility within the core system itself rather than delegating it to a separate platform. The criterion is straightforward: if the integration landscape is going to grow, or if external parties are inconsistent or unpredictable in their API management, a central layer pays for itself. If it stays stable and small, a direct connection is simply good engineering.
What you can do if you build without middleware anyway
If the choice for direct API connections is deliberate and well-founded, three things make the difference. First: build error handling and retry logic in from day one, not as an afterthought. Second: document which API version is in use per connection and maintain a register, even if it is just a simple table. Third: set up alerting on message volume, not only on HTTP error codes. A connection that has gone silent often returns no error; it simply stops sending. These three measures address the biggest risks without requiring a full middleware platform. They cost time during the build, but that time is recovered the moment the first external API update or the first incident arrives.