Third-Party ERP Integrations: Patterns and Pitfalls

Why ERP Integration Is Where Projects Go Sideways

The ERP implementation is going smoothly. The core modules are configured, the data migration is planned, and the team is on schedule. Then integration work begins.

The accounting system needs to receive journal entries from the ERP. The e-commerce platform needs real-time inventory levels. The shipping carrier API needs to create labels and track packages. The payment processor needs to handle refunds. The vendor EDI system needs to exchange purchase orders and invoices in a format from 1985.

Each integration seems like a bounded, manageable task. But integration projects routinely take 2-3x longer than estimated because the complexity isn't in connecting two systems — it's in handling the mismatch between how those systems model the world.

Your ERP thinks an "order" is an entity with line items, payment terms, and a shipping address. Your e-commerce platform thinks an "order" is a transaction with a cart, a checkout session, and a fulfillment record. These aren't the same thing. The translation between them involves business decisions, not just data mapping.

Integration Architecture: Decoupled by Default

The most important architectural decision is where the translation logic lives and how the systems communicate.

Point-to-point integration connects systems directly. The ERP calls the accounting API to post a journal entry. The e-commerce platform calls the ERP API to check inventory. This is the simplest approach for a small number of integrations, but it creates tight coupling. Each system needs to know about the other system's API, handle its errors, and adapt to its changes. With N systems, you potentially have N*(N-1) integration paths to maintain.

Hub-and-spoke integration routes all data through a central integration layer. Systems send data to the hub and receive data from the hub. The hub handles translation, routing, and error management. Each system only needs to integrate with the hub, reducing the integration surface from N*(N-1) to 2*N. This is the pattern behind integration platforms like MuleSoft, Boomi, and custom integration middleware.

Event-driven integration publishes domain events to a message broker. When the ERP creates a journal entry, it publishes a JournalEntryCreated event. The accounting system subscribes to this event and processes it. Systems don't call each other — they publish and subscribe to events through a shared messaging infrastructure.

For most custom ERP implementations, I recommend a combination: event-driven integration for data synchronization (keeping systems in sync as changes occur) and direct API calls for real-time queries (checking inventory availability, validating a tax ID). The event-driven path handles the high-volume, eventually-consistent flows. The API path handles the low-volume, immediately-consistent queries.

Data Mapping and Transformation

The core work of integration is data mapping: translating entities, fields, and values between two systems that model the same business concepts differently.

Entity mapping defines which entities in each system correspond to each other. An ERP "sales order" might map to an e-commerce "order" plus a "fulfillment request." An ERP "customer" might map to a CRM "account" plus one or more "contacts." These mappings aren't always one-to-one, and the mismatch is where bugs hide.

Field mapping defines which fields in each system correspond to each other and how values are translated. The ERP stores state codes ("TX"), the accounting system stores state names ("Texas"). The ERP uses internal product IDs, the e-commerce platform uses SKUs. The ERP stores amounts in cents, the API expects dollars with two decimal places. Each field mapping needs explicit translation logic.

Reference data alignment ensures that both systems agree on shared values. If the ERP has a payment term "Net 30" with ID 5, the accounting system might have the same concept with a different ID. Reference data mapping tables maintain the cross-system lookup.

Conflict resolution defines what happens when the same data is modified in both systems. If a customer's address is updated in the CRM and in the ERP simultaneously, which wins? The answer is usually "the system of record wins" — one system is the authoritative source for each data type, and the integration propagates changes from the authoritative source to the consuming systems.

Store mapping configurations as data rather than hardcoded logic. When the e-commerce platform adds a new order status, you should be able to add the mapping in a configuration table without deploying code. The patterns from enterprise integration patterns provide a proven vocabulary for these transformation concerns.

Error Handling and Monitoring

Integration errors are inevitable. APIs return 500 errors. Messages get malformed. Rate limits get hit. Network connections drop. The system needs to handle all of these gracefully.

Retry with exponential backoff handles transient failures. A 500 error from the accounting API might clear on the next attempt. Retry three times with increasing delays before marking the integration attempt as failed. Idempotency is critical here — retrying a journal entry creation must not create duplicate entries. Use idempotency keys in the integration layer.

Dead letter queues collect messages that fail permanently after retries. An operations team reviews dead letter items, fixes the underlying issue (bad data, missing mapping, configuration error), and replays the messages. This is the same pattern used in batch processing for handling individual record failures.

Circuit breakers prevent cascading failures. If the shipping carrier API is down, continuing to send requests wastes resources and may cause timeout issues in the calling system. A circuit breaker detects repeated failures, stops sending requests for a configurable period, and periodically tests whether the service has recovered. During the circuit-open period, operations that require the integration can be queued or handled with a fallback.

Integration monitoring needs to track success rates, latency, and data freshness for each integration. A dashboard showing that the inventory sync has been failing for 2 hours is the difference between catching a problem during business hours and discovering Monday morning that the entire weekend's orders were oversold.

Versioning and Change Management

Third-party APIs change. Vendors release new versions, deprecate old endpoints, modify field formats, and add required fields. Your integration needs to handle this without breaking.

API versioning in your integration layer. When you build the integration, pin it to a specific API version. When the vendor releases a new version, you test and migrate on your schedule rather than being forced by the vendor's deprecation timeline.

Schema validation at the boundary. Validate incoming data against expected schemas before processing. When the vendor changes their response format, schema validation catches the mismatch immediately with a clear error rather than allowing corrupt data into your system where it causes downstream failures.

Adapter pattern for vendor abstraction. If you're integrating with a shipping carrier, don't embed FedEx-specific logic throughout your codebase. Build a shipping adapter interface that your application uses, and implement FedEx-specific logic behind that interface. When you add UPS or switch carriers, you add a new adapter implementation without touching the application.

Integration is where the theory of clean architecture meets the messy reality of external systems. The discipline of maintaining clean boundaries between your system and the external world pays dividends every time a vendor changes their API or you need to swap one service for another.

If you're planning ERP integrations, let's discuss the architecture.