How to Choose the Right ERP Integration Pattern

What is the best way to integrate ERP with other business systems?

There isn't one correct pattern. The right integration depends on what the receiving system does with the data and how fast it needs to act on it.

Most CTOs default to API-first because it's familiar, then discover it doesn't fit every case. A sales order needs a synchronous answer: is there stock, yes or no. A dispatch confirmation doesn't need an answer at all, it just needs to be known by three other systems eventually. Treating both the same way is where integration debt starts.

The decision isn't technical first. It's operational. Ask who is waiting for this data, and what they do if it's five minutes late.

What's the difference between API-first, event-driven and batch sync?

Each pattern answers a different operational question: does someone need an immediate answer, does a system need to react to a change, or does data just need to be reconciled periodically.

API-first is a direct, synchronous call between two systems. The CRM asks the ERP "is there stock for this SKU" and waits for an answer before the salesperson can confirm the order. It's the right choice when the business decision depends on the answer arriving now.

Event-driven is asynchronous. A system publishes "order confirmed" or "stock dispatched" as an event, and anything subscribed to that event reacts in its own time. The ERP doesn't wait for the WMS to confirm it received the message. This fits one-way notifications where the sender doesn't need to know the outcome immediately.

Batch sync moves data in scheduled bulk jobs, usually overnight or hourly. It fits reconciliation, not decisions. Nightly stock counts, finance exports, CRM contact updates. Nobody is standing at a screen waiting for this to finish.

Pattern	Latency	Direction	Failure handling	Best for
API-first	Seconds	Synchronous, two-way	Caller must handle timeout/retry	Stock checks, order creation, credit limit checks
Event-driven	Seconds to minutes	Asynchronous, one-way	Queue retries, dead-letter handling	Dispatch notifications, status updates, cross-system triggers
Batch sync	Hours	Bulk, scheduled	Reconciliation job catches mismatches	Nightly stock sync, finance exports, master data refresh

How do you decide which pattern fits a given integration?

Decide by asking whether a human or another system is blocked waiting for the answer, not by which pattern your team already knows how to build.

If the answer needs a phone call, it's not a system. That's the test for API-first: if a stock check takes too long or fails silently, someone on the floor will pick up the phone to ask the stores clerk directly, and the integration has already failed its purpose.

For event-driven cases, the test is different. Ask whether the sending system needs to know the outcome. If the ERP publishes a dispatch event and the CRM takes three minutes to update the customer's delivery status, nothing breaks. That's an event, not an API call.

For batch sync, the test is whether anyone is making a decision between runs. If the sales team only checks consolidated stock once a day before placing orders, a nightly batch is enough. Building a real-time API for that is effort spent on a problem that doesn't exist.

What does this look like for ERP, CRM and shop floor systems together?

In practice, a single order touches all three patterns depending on which step you're looking at, not just one pattern for the whole flow.

Take a sales order moving from CRM to ERP to the shop floor. The CRM needs an immediate stock answer before the salesperson commits a delivery date, that's API-first. Once the order is confirmed, the ERP doesn't need the WMS to acknowledge the pick list in real time, that's event-driven. And the finance team's nightly reconciliation between ERP and the accounting system is a batch job, because nobody needs it until the next morning.

Teams get into trouble when they force one pattern across the whole chain. Building everything as synchronous API calls makes the CRM dependent on the WMS being online, which it doesn't need to be. Building everything as batch means the salesperson is quoting stock that's twelve hours stale. The shop floor interface for this handoff is its own decision, covered in Mobile App or Web Dashboard for Shop Floor Operations, but the integration pattern feeding it is decided separately, by latency need, not by screen type.

Where does integration debt come from?

Integration debt builds when every new system gets a direct, point-to-point connection instead of a shared layer, and nobody owns the growing web of connections.

Three systems need three connections. Five systems, if every pair talks directly, need ten. Add a sixth and it's fifteen. Each one has its own retry logic, its own field mapping, its own undocumented assumption about what "active customer" means. When the ERP changes a field name, four other systems break and nobody remembers why they were connected in the first place.

This is the same pattern described in Technical Debt in an Internal Tool: When to Pay It Down. Integration debt isn't messy code. It's connections the business can no longer trace without a developer tracking down which job failed overnight.

When do you need a dedicated integration layer instead of more point-to-point connections?

Bring in a middleware layer, an iPaaS or a custom integration service, the moment a third system needs the same piece of data as the first two.

Two systems talking directly is fine. The moment a third system needs the same customer record, stock figure or order status, route it through one layer instead of adding a third direct connection. The layer becomes the single place that knows the field mappings, the retry rules and who owns what. It's the same principle behind introducing a reporting layer once a second source feeds the same report, covered in Designing a Reporting Architecture for Multiple Sources.

This isn't a call to rebuild everything on day one. Start point-to-point if there are only two systems. Plan the layer before the third one goes live, not after the fourth integration breaks in production. And when picking the stack for that layer, the same constraint applies as any other internal system: choose what your team can support in three years, a point covered in How to Choose a Tech Stack When the Business Has to Live With It.

What to do next

Map every system that currently talks to your ERP and write down, for each connection, whether it's a decision, a notification or a reconciliation. That one column tells you which pattern you actually need, and usually reveals two or three point-to-point connections that should never have been built that way.

If that map is bigger than you expected, that's the conversation worth having before the next system gets added. A free 30-minute call is enough to walk through what you have and where it's heading. For the wider set of build, migrate and MVP decisions this sits inside, see the Building Software hub.