Integration Middleware vs Point-to-Point APIs
Direct API connections are quick to build and hard to live with at scale. Middleware adds a platform to run. Here is how to tell which one your landscape needs.
Every Salesforce integration starts as a single connection, and a direct API call is usually the quickest way to build it. The difficulty appears with the fifth or tenth connection, when the same customer data is transformed in four places and nobody can say which integration failed overnight. Middleware solves that, at the cost of another platform to license, learn and operate.
Point-to-point integrations
A point-to-point integration connects two systems directly. Common Salesforce examples:
- Apex callouts or External Services calling an ERP or payment API, authenticated through Named Credentials.
- An external application calling the Salesforce REST or Bulk API to create or update records.
- A subscriber listening to Platform Events or Change Data Capture to react to changes in Salesforce.
Strengths: few moving parts, low cost, fast to deliver, and simple to reason about when only a couple of systems are involved.
Weaknesses: the number of connections grows quickly as systems are added, transformation logic gets duplicated, monitoring is spread across systems, and a change in one API can ripple into several others.
Middleware
Middleware (an integration platform such as MuleSoft, Boomi or a cloud provider's integration services) sits between systems. It handles transformation, routing, retries, queuing and monitoring in one place, and often exposes reusable APIs that several consumers share.
Strengths: central visibility, consistent error handling, reuse, and the ability to change one system without rewriting every consumer.
Weaknesses: licence and infrastructure cost, specialist skills, another layer that can fail, and extra latency. It can also become a bottleneck if one small team must approve every change.
At a glance
| Point-to-point | Middleware | |
|---|---|---|
| Best scale | Two to a few systems | Many systems and consumers |
| Time to first integration | Short | Longer, platform set-up first |
| Transformation logic | In each connection | Centralised and reusable |
| Error handling and retries | Built per connection | Common patterns and tooling |
| Monitoring | Spread across systems | One place to look |
| Cost profile | Low entry, grows with maintenance | Higher entry, flatter growth |
| Skills | Salesforce and source-system developers | Integration platform specialists |
| Main risk | Tangled dependencies over time | Overhead and bottlenecks |
Decision criteria
- Number of systems and consumers. Two systems with one data flow rarely justify middleware. Several systems sharing customer, product and order data usually do.
- Rate of change. If source systems are being replaced or upgraded, an abstraction layer protects Salesforce from those changes.
- Error handling and audit needs. Regulated processes, financial data and order flows need dependable retries, dead-letter handling and traceability. Building that well into every point-to-point connection is expensive.
- Volume and latency. High-volume batch loads and near-real-time events both work either way, but the patterns differ. Check current API limits for your org in Salesforce Help before designing.
- Team and ownership. Middleware without an owning team degrades fast. If nobody will run it, a small number of well-built direct integrations is safer.
- Budget horizon. Compare the cost of maintaining many direct connections over several years, not just the cost of building the next one.
Whichever you choose, standardise the message
A consistent event or message structure makes both patterns easier to monitor and easier to migrate later. A correlation ID that travels with every message is the single most useful habit for diagnosing failures. An event ID lets the receiving system ignore duplicates, which matters because retries, whether from middleware or from your own code, will eventually deliver the same message twice. Agree field names, date formats and currency handling once, and publish them where every integration developer can find them.
{
"eventType": "OrderCreated",
"eventId": "9f1c2e7a-0000-4000-8000-000000000001",
"occurredAt": "2026-10-18T09:30:00Z",
"source": "erp",
"correlationId": "ord-100045",
"payload": {
"orderNumber": "100045",
"customerExternalId": "CUST-2231",
"currency": "INR",
"totalAmount": 4599.00
}
}Moving from point-to-point to middleware gradually
- 01
Map what exists
List every integration with its systems, direction, frequency, owner, authentication and failure handling. Most teams find connections nobody remembered.
- 02
Find the shared data
Identify the entities several integrations touch, typically customer, product and order. These are the first candidates for reusable APIs.
- 03
Agree conventions first
Define the message structure, error codes, retry policy, logging and correlation IDs before building anything new.
- 04
Route new integrations through the platform
Avoid a big-bang rewrite. New work uses middleware; existing connections move when they need significant change anyway.
- 05
Retire direct connections deliberately
Run old and new in parallel with reconciliation, then switch off the direct path and remove its credentials.
Our view: it depends on how many systems you will connect
For a small landscape with stable systems, well-built point-to-point integrations using Named Credentials, Platform Events and proper error handling are often the right answer. Once you expect several systems to share core data, or you need central monitoring and audit, middleware usually earns its cost. Many organisations sit in the middle: a handful of direct, event-driven integrations today, with a plan to introduce middleware when the landscape grows. Our integration error handling checklist applies to both.
Questions we hear
Is middleware always needed with Salesforce?
Are Platform Events a form of middleware?
How do we secure point-to-point integrations?
What should we monitor regardless of pattern?
Does middleware slow integrations down?
Review your integration landscape
We can map your current integrations, highlight the fragile ones and recommend whether direct APIs or middleware fit your next phase. See our integration services.
