Direct API integration connects System A to System B with code or a connector that knows both sides. Middleware inserts a dedicated layer that can serve many connections with shared mapping, monitoring, and orchestration. Neither pattern is universally best; the right choice depends on scale, volatility, and who will operate failures at 2 a.m.
When direct API integration is appropriate
- One or two stable links with simple field mappings
- Low volume and a clear single owner
- Vendor-provided connectors that already meet audit needs
- Short-lived bridges while a larger platform decision is pending
Direct links minimise moving parts. They become painful when every new channel needs another pairwise custom link and nobody can see end-to-end status.
When middleware is the better investment
- Multiple sources writing into one system of record (or the reverse)
- Complex data mapping, enrichment, or multi-step posts before the ledger updates
- Need for centralised retries, replay, and logging (see how middleware works)
- Anticipated replacement of one endpoint system without rewriting all neighbours
Decision matrix
Score each critical flow from 1–5 on the factors below. High totals push toward middleware; low totals can stay direct.
| Factor | Low score (favor direct) | High score (favor middleware) |
|---|---|---|
| Systems touched | Two systems, one direction | Three or more systems or fan-out |
| Mapping complexity | Few fields, stable codes | Tax, SKUs, multi-branch rules |
| Failure / replay need | Occasional manual fix OK | Must retry, quarantine, and prove audit |
| Endpoint volatility | Unlikely to replace either side | Likely to change ecommerce, POS, or ERP |
| Compliance sensitivity | Low-risk notifications | Money, tax, or regulated submissions |
Also weigh organisational fit: a company with no one to own a hub should not build a sophisticated middleware platform on day one.
Choosing an integration pattern
- List systems and critical flows
- Score mapping and failure complexity
- Assess monitoring and ownership capacity
- Pick direct, middleware, or hybrid
- Pilot the highest-risk flow first
Concrete scenario: ecommerce + POS → accounting
A retail brand sells online and in stores. Both channels must create sales documents in accounting, keep SKU and tax codes aligned, and avoid double-counting when an online order is picked up in-store.
Direct approach: build an ecommerce→accounting connector and a separate POS→accounting connector. Each team owns its mapping. When tax codes change, two places need updates. Pickup orders risk posting twice unless both connectors implement the same dedupe rules.
Middleware approach: both channels publish order events to a hub. One mapping set translates products and tax into accounting documents; one idempotency strategy keys on channel order ID; operators see one failure queue. Swapping the ecommerce platform later means replacing one adapter, not rewriting accounting logic twice.
Practical hybrid: keep a simple direct sync for a low-volume side channel (for example gift-card balances), and put money-moving sales posts behind the hub. Consistency of pattern matters more than purity.
For product-specific wiring notes, see connecting AutoCount to ecommerce or POS. For compliance APIs vs portals, see MyInvois portal vs API & middleware.
Cost and maintenance lens
Direct may be cheaper to start and costlier to evolve. Middleware may cost more upfront and cheaper when the fifth integration arrives—if someone owns it. Budget for operations either way; unattended integrations eventually surprise you.
Migration path
You can wrap an existing direct integration with a thin façade later. Document mappings outside code (config tables) so evolution does not require archaeology. See what is middleware for hub responsibilities.
FAQ
Is an iPaaS always middleware?
Functionally yes when it orchestrates and transforms between systems. Governance still matters; visual flows without owners become shadow IT.
Can we start direct and move to a hub later?
Yes—if you keep mappings and business keys explicit. Hard-coding vendor field names in many scripts makes the migration expensive.
Does middleware always mean higher latency?
Not necessarily. A well-built hub can be near real time. Latency problems usually come from polling intervals, rate limits, or synchronous multi-hop designs—not from the idea of a hub itself.
Who decides pattern per flow?
Architecture with the process owner for that flow. Finance-critical posts deserve stricter standards than marketing notification syncs.
What should we pilot first?
The flow with the highest cost of failure or the most mapping pain—not the easiest demo—so the pattern proves itself under real constraints.
Related concepts
Hub definition: what is middleware. Runtime controls: how middleware works. Accounting posting patterns: how accounting software integration works.