Adobe Commerce API Integration with ERP and CRM Systems: A Technical Guide
The integration between Adobe Commerce and the enterprise's ERP and CRM systems is where most B2B eCommerce builds either succeed quietly or fail loudly. Done well, the integration is invisible: orders flow into the ERP, customers flow into the CRM, inventory levels stay accurate, pricing reflects contract terms, and the eCommerce platform feels like an extension of the back-office systems rather than a parallel universe with its own data. Done badly, the integration becomes the source of every operational issue the platform produces, from incorrect pricing to lost orders to customer service escalations that nobody can resolve.
The pattern in successful Adobe Commerce integrations is consistent. The teams that do this well make a small number of architectural decisions early that compound positively, and they avoid a small number of mistakes that recur in failing integrations across every industry.
The Architectural Decisions That Determine Integration Success
Before writing any code, several architectural decisions need to be made deliberately. These choices shape the integration's reliability, maintainability, and ability to evolve with the business.
Which system is the source of truth for which data? This is the foundational question and the one most teams skip. Customer master data: ERP or CRM? Product master data: PIM, ERP, or Adobe Commerce? Pricing: ERP or commerce? Order data: ERP after sync, or commerce until shipped? The answer should be deliberate, documented, and respected across every integration. Ambiguity here produces sync conflicts, data quality issues, and operational confusion that compounds.
In most B2B contexts, the right defaults are: ERP for inventory, pricing, and order fulfillment; CRM for customer interactions and sales activity; PIM (if present) or Adobe Commerce for product content and marketing attributes. The eCommerce platform owns the customer-facing experience but defers to the back-office systems for the data they authoritatively maintain.
Synchronous or asynchronous integration? Synchronous integrations are conceptually simpler — the eCommerce platform makes an API call to the ERP and waits for the response. They are also fragile: when the ERP is slow or unavailable, the eCommerce platform feels the pain immediately. Asynchronous integrations, where the eCommerce platform writes to a queue and the integration layer handles the eventual delivery, are more resilient but require more architectural discipline.
For most production integrations, asynchronous patterns are the right default. Synchronous integration is appropriate only when the eCommerce platform genuinely cannot proceed without an authoritative response (e.g., real-time inventory verification before allowing an add-to-cart for last-unit scenarios). Even in those cases, the synchronous call should have aggressive timeouts and graceful fallbacks.
Where does the integration logic live? Three common architectures: integration inside Adobe Commerce (modules and observers), integration inside the ERP/CRM (extensions and connectors), integration in a middleware layer (iPaaS, custom services, or message broker). Each has tradeoffs. Integration inside Adobe Commerce tightly couples the eCommerce platform to the back-office systems and creates upgrade fragility. Integration inside the ERP/CRM concentrates risk in those systems. Middleware integration is the most flexible and the most expensive to set up but scales the best as integration complexity grows.
For most enterprise integrations of meaningful complexity, the middleware approach pays back its setup cost within 12-18 months through reduced operational overhead and cleaner change management.
How do conflicts get resolved? Distributed data systems will produce conflicts. A customer updates their address in the ERP, the eCommerce platform updates the same customer's address from a checkout, and the two updates arrive at the integration layer in close succession. Which one wins? The conflict resolution rules need to be defined explicitly: which system has authoritative write access for which fields, what happens when both systems write to the same field, and how conflicts get logged and audited. Teams that defer this decision discover conflicts in production, when the cost of resolving them is multiples higher.
The Adobe Commerce API Surface
Adobe Commerce exposes a comprehensive REST API surface, plus GraphQL, plus SOAP for legacy integrations. The API documentation is mature but extensive, and the practical integration work usually involves understanding which endpoints support which use cases and where the gaps are.
Customer data. The customer API supports create, update, search, and authentication operations. For ERP-driven customer creation, the integration typically creates customers through the API on first order, with subsequent updates flowing from the ERP. For CRM-driven customer creation, the pattern is similar but the data shape might be different (more lifecycle metadata, less transactional history).
Product data. The product API supports the full lifecycle of products, including configurable products, bundles, custom options, and complex attribute structures. For PIM-driven product management, the PIM is the source of truth, and the integration syncs to Adobe Commerce on a schedule. For Adobe Commerce-driven product management, the platform's admin is the source of truth and the integration syncs out to the ERP for ordering and fulfillment.
Pricing. Adobe Commerce's pricing engine supports customer-specific pricing through customer groups and customer-specific price lists. For complex B2B pricing scenarios — contract pricing per customer, volume discounts, role-based pricing — the architecture often involves the ERP holding the authoritative contract terms and the integration pushing the resolved prices into Adobe Commerce on a customer-by-customer basis.
Orders. Order data flows in both directions: orders created in Adobe Commerce flow to the ERP for fulfillment, and order status updates flow back from the ERP to Adobe Commerce for customer-facing visibility. The integration needs to handle the full lifecycle: order creation, payment authorization, fulfillment status, shipment tracking, returns, and credit memos.
Inventory. Adobe Commerce's multi-source inventory (MSI) supports complex inventory scenarios: multiple warehouses, location-based stock, reservation logic during checkout. For ERP-managed inventory, the integration syncs inventory levels from the ERP into Adobe Commerce on a cadence (every 5-15 minutes is typical for fast-moving products; longer cadences are acceptable for slow-moving items). For real-time inventory verification at critical decision points (last-unit checkout, configured products with shared components), synchronous lookups complement the cached inventory.
The Adobe Commerce REST API documentation and GraphQL documentation are comprehensive references. The practical work is understanding which API to use for which scenario, given the performance, consistency, and operational characteristics of each.
The Common Integration Patterns
Across hundreds of Adobe Commerce integrations, certain patterns recur. Recognizing them helps teams pick the right approach for their specific situation.
The reservation-and-confirm pattern. Used for inventory in checkout. The eCommerce platform places a reservation on inventory when the customer enters checkout, then confirms or releases the reservation based on whether the order completes. This pattern requires synchronous coordination with the inventory system but produces the cleanest customer experience for inventory-sensitive products.
The eventually-consistent customer master pattern. Used for customer data when the ERP and the eCommerce platform both need to read and write. Updates are queued, sequenced by timestamp, and applied with conflict resolution rules. The customer might see a stale view briefly during update propagation, but the systems converge quickly and the data remains coherent across the integration.
The dual-write order pattern. Used for order data when both Adobe Commerce and the ERP need to maintain authoritative views. The order is written first to Adobe Commerce (which produces the customer-facing order acknowledgment), then asynchronously written to the ERP. The integration layer monitors the sync and surfaces failures for manual reconciliation.
The catalog-sync pattern. Used for product data when the PIM or ERP is the source of truth. The catalog data is pushed to Adobe Commerce on a schedule, with delta-only updates after the initial load. The catalog is read-only inside Adobe Commerce's admin to prevent drift.
The pricing-resolution-on-demand pattern. Used for complex B2B pricing where pre-computed customer-specific prices are infeasible. The eCommerce platform calls the ERP's pricing engine in real time when a customer adds a product to cart or requests a quote. The pricing call is synchronous but bounded by aggressive timeouts and cached for the customer's session.
| Pattern | Use Case | Key Tradeoff |
|---|---|---|
| Reservation-and-confirm | Inventory in checkout | Requires real-time inventory access |
| Eventually-consistent customer | Customer master sync | Brief staleness during propagation |
| Dual-write order | Orders with multiple systems of record | Requires reconciliation tooling |
| Catalog sync | Product data from PIM/ERP | Delta logic complexity |
| Pricing-on-demand | Complex B2B pricing | Performance at scale |
The Integration Layer Tooling Decisions
Beyond the architecture, the actual tooling that implements the integration shapes its operational characteristics.
iPaaS platforms. Tools like MuleSoft, Boomi, and Workato provide managed integration services. They are expensive but mature, with built-in error handling, monitoring, and security. For enterprises with multiple integrations across their broader IT estate, the iPaaS approach is usually justified by the operational consistency it provides.
Custom middleware. For specific integration patterns or for organizations with strong development capabilities, custom middleware in Node.js, Python, or Java can be more cost-effective than iPaaS and more flexible than vendor extensions. The tradeoff is operational ownership: the custom middleware needs monitoring, alerting, and runbooks that iPaaS provides out of the box.
Native ERP/CRM connectors. Many ERPs and CRMs ship with Adobe Commerce connectors (SAP, NetSuite, Microsoft Dynamics, Salesforce). These connectors handle common patterns out of the box and reduce the development effort for standard integrations. They sometimes struggle with custom scenarios and can be fragile across platform upgrades, but they are usually the right starting point.
Message brokers and event buses. Kafka, RabbitMQ, AWS EventBridge, and similar tools provide the asynchronous communication backbone for event-driven integrations. They are appropriate when the integration has multiple consumers, complex routing, or strong audit requirements. For simpler integrations, a basic message queue is usually sufficient.
What Bemeir's Approach Looks Like
In Adobe Commerce integration work with enterprise clients, Bemeir's team typically starts with the architectural conversation rather than the tooling conversation. The patterns above shape the recommendation. The tooling follows the pattern, not the other way around.
For Hyvä-based storefronts, the integration architecture sits behind the storefront and is largely invisible from the front-end perspective. The Hyvä frontend calls Adobe Commerce; Adobe Commerce calls the integration layer; the integration layer talks to the back-office systems. The clean separation makes the storefront simpler and the integration logic more focused.
For complex B2B scenarios, the integration work typically involves customer hierarchy syncing from the ERP, customer-specific pricing pulled from contract data, order approval workflows that span the commerce platform and the ERP, and reporting integrations that surface eCommerce metrics in the enterprise's standard BI tooling. According to research from Forrester on B2B eCommerce platform integration, enterprises with mature ERP-commerce integration architecture achieve 40-60% lower per-order operational cost than enterprises operating siloed systems.
The integration work is rarely glamorous. It is the structural plumbing that determines whether the platform actually works in production. The agencies that do this well bring discipline to the architectural decisions, experience with the common patterns, and operational maturity that survives the inevitable changes in business requirements and back-office systems. For Adobe Commerce builds in enterprise environments, that capability is usually worth more than any individual feature in the platform's marketing material.
Get the integration architecture right, and the rest of the platform decisions get easier. Get it wrong, and every subsequent decision pays a tax that compounds for years.
