Magento and Adobe Commerce ERP Integration

Magento — today Magento Open Source and Adobe Commerce — is the most extensible of the four platforms covered here, and the one with the most ways to build an integration. That flexibility is useful and a source of risk: two Magento ERP integrations can share almost no architecture. Documented statements below come from Adobe’s documentation; recommendations are ours.

How Adobe Commerce connects to an ERP

Documented: Adobe Commerce and Magento Open Source provide REST and SOAP web APIs. API resources and their permissions are defined in webapi.xml and the ACL; integrations are created in the Admin with access to selected API resources. Asynchronous endpoints accept requests that are queued and executed by message queue consumers, and return a bulk_uuid for checking status.

Documented: Adobe Commerce provides Adobe I/O Events for event-driven, asynchronous integrations — for example, registering an order placement event that Adobe I/O routes to an App Builder application, which then calls Commerce APIs for details. It also provides Adobe Commerce Webhooks for synchronous calls to external systems when Commerce must compute or validate something immediately; Adobe advises creating a webhook only if synchronous communication is critical, and suggests I/O Events for most other scenarios.

Recommendation: for most ERP flows, use asynchronous mechanisms (events or polling plus queues). Reserve synchronous webhooks for genuinely real-time needs such as live price or stock checks at checkout, where the ERP’s latency directly affects the shopper.

Common integration use cases

• Order export to the ERP after placement or invoicing.
• Product, price, and attribute import from the ERP or PIM, often in bulk.
• Source-level inventory updates from warehouses.
• Shipment and invoice creation from ERP events.
• B2B company accounts, shared catalogs, and negotiated pricing (Adobe Commerce B2B).

Order synchronization

Recommendation: trigger export from an order event (I/O Events or an observer in a custom module) or poll orders updated since a checkpoint, fetch the order through the REST API, and store the Magento order increment ID together with the store or website as the ERP external reference. Decide whether orders export at placement or at invoice, depending on your payment capture process.

Inventory synchronization

Documented: Inventory Management (often called MSI) uses sources — physical locations that store and ship products — and stocks, which map a sales channel (website) to sources. It tracks on-hand quantity per source and an aggregate salable quantity, and protects inventory during checkout. A stock can map to multiple sales channels, but a sales channel can be assigned to only one stock.

Recommendation: map each ERP warehouse to a source and update source quantities. Do not try to write salable quantity directly — it is derived from source quantities and order reservations. For high-volume updates, use asynchronous or bulk endpoints.

Product and variant synchronization

Documented: configurable products are composed of simple child products, each with its own SKU. The asynchronous and bulk APIs support product create and update operations.

Recommendation: map each simple product (child) to one ERP article by SKU, and treat configurable parents as merchandising containers. Large attribute-rich catalogs often benefit from a PIM between the ERP and Adobe Commerce. See mapping products to ERP SKUs.

Customer data synchronization

Recommendation: for B2B, synchronize companies, company users, and credit limits deliberately, matching on IDs stored in both systems. For B2C, consider a generic web customer in the ERP as with other platforms.

Fulfillment and shipment updates

Recommendation: create shipments (with tracking) and invoices in Commerce from ERP shipment and billing events, using the ERP document IDs to prevent duplicates on retry. Multi-source setups may need source selection logic aligned with the ERP’s actual shipping warehouse.

API and webhook considerations

Documented:

• Asynchronous and bulk requests require the relevant message queue consumer (for PaaS, the async.operations.all consumer) to be running.
• In Adobe Commerce as a Cloud Service, some API paths differ — for example, where the /async segment appears and how the store is specified.
• Webhooks resolve as successful, by throwing an exception, or by modifying the event payload, and run synchronously.

Recommendation:

• Monitor message queue consumers and cron; stopped consumers silently stall bulk imports.
• Check bulk operation status after submission and alert on failed operations.
• Version your integration against your specific edition and deployment type, and test after every platform upgrade.

Common implementation challenges

• Stopped cron or queue consumers leaving async operations pending.
• Extension conflicts where third-party modules alter order or product data.
• Upgrade risk for in-process integration modules.
• Writing salable quantity instead of source quantity.
• Store view and website scope confusion for prices, attributes, and stock.

Direct integration vs. middleware

Adobe Commerce integrations range from custom modules, to external services, to Adobe App Builder applications, to iPaaS products and prebuilt ERP connectors. For a custom ERP, an external service or App Builder app using the web APIs and I/O Events keeps the ERP integration out of the store’s code deployment. See direct integration vs. middleware.