Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
A Magento ERP integration connects your store to the system that runs finance, inventory and fulfillment, so orders flow out of Magento and stock, prices and shipment updates flow back in without manual re-keying. The right design depends less on which ERP you run and more on three decisions: which system owns each piece of data, how fresh each data flow must be, and how failures are retried and reported. Get those right and the choice between a ready-made connector, middleware or a custom integration becomes much easier.
Start with data ownership
Many integration problems trace back to two systems both thinking they own the same data. Before choosing tools, write down a single owner for each data type. A typical split looks like this:
- ERP owns: stock levels, cost and list prices, customer-specific B2B pricing, credit limits, invoices, item master data such as SKU, weight and tax class.
- Magento owns: the order as placed, cart and checkout data, storefront content, guest customers, promotions configured for the web.
- A PIM, if you have one, owns: marketing descriptions, images, attributes for filtering. See our Magento PIM integration guide for how a PIM fits next to the ERP.
Shared records, such as B2B customer accounts and addresses, need explicit rules for which side wins when both change.
Data-flow table: direction and frequency
This table is a starting template for scoping. Frequencies are typical targets, not fixed rules; adjust them to your order volume, stock risk and ERP limits.
| Data | Direction | Typical frequency | Trigger and method | Notes |
|---|---|---|---|---|
| Orders | Magento to ERP | Near real time (seconds to minutes) | Order-placed event or queue; REST order endpoints | Include payment, tax and discount lines so totals reconcile |
| Order status, shipments, tracking | ERP to Magento | Near real time or every few minutes | ERP push or polling; REST shipment and invoice endpoints | Triggers customer emails, so avoid duplicates |
| Stock levels | ERP (or WMS) to Magento | Every few minutes for fast movers; deltas only | Async bulk REST or inventory source updates | Send changed SKUs only; full refresh nightly as a safety net |
| Prices (list) | ERP to Magento | Scheduled, often daily or on change | Async bulk REST or import | Coordinate with indexers and cache flushes |
| Customer-specific and tier prices (B2B) | ERP to Magento | On change, plus nightly reconcile | Bulk updates to shared catalogs or tier prices, or real-time price lookup | Large matrices may suit a real-time price service instead of copying |
| Customers and companies | Both directions | On create or change | Events from both sides; match on a stable external ID | Define which fields each side may update |
| Product master data (SKU, weight, tax class) | ERP (or PIM) to Magento | On change or daily | Bulk import | Never let the store create SKUs the ERP does not know |
| Invoices and credit memos | ERP to Magento | On creation | REST | Needed for customer account history and B2B self-service |
| Returns (RMA) | Magento to ERP, status back | On request and status change | Events plus REST | Agree who approves and who issues refunds |
For the API choice behind each flow, our Magento GraphQL vs REST guide explains why integrations normally use REST, including the asynchronous bulk endpoints for high-volume updates.
Four integration patterns
1. Connector module inside Magento
A PHP extension installed in Magento talks directly to the ERP's API. It is quick to start and keeps everything in one place. The trade-off: the integration now runs inside your store, competes for its resources and becomes part of every Magento upgrade.
2. Middleware or iPaaS
An integration platform sits between Magento and the ERP, mapping fields, queuing messages and retrying failures. This suits companies with several systems (ERP, WMS, CRM, marketplaces) or an existing integration team. It adds a subscription and another platform to monitor.
3. Event-driven, out-of-process (Adobe Commerce)
On Adobe Commerce, Adobe I/O Events can send order and customer events to an App Builder app that transforms and forwards them. Adobe publishes an integration starter kit for back-office systems as a scaffold. This keeps the integration out of the Commerce codebase and scales independently. Our Adobe App Builder guide covers the trade-offs.
4. File-based exchange
Scheduled CSV or XML files over SFTP. Older ERPs still rely on it. It is simple and robust for nightly prices or catalogs, but too slow for stock or order status on a busy store.
Common pitfalls
- Synchronous calls in checkout. Calling the ERP live during checkout for stock or price makes checkout as slow and as available as the ERP. If you need real-time checks, set strict timeouts and a fallback.
- Full stock refreshes every few minutes. Pushing the whole catalog repeatedly triggers indexing and cache invalidation. Send deltas.
- No idempotency. Retries create duplicate orders in the ERP unless each message carries a unique ID the ERP checks.
- Silent failures. A failed message nobody sees becomes an unshipped order. Build a failure queue, alerts and a screen where staff can re-send.
- Mismatched totals. Rounding, tax and discount allocation differ between systems. Agree rules early and test with real baskets.
- Forgotten edge cases. Partial shipments, split payments, bundles, configurable products, gift cards and returns.
- Indexer load. Large price or stock updates trigger reindexing; make sure indexers run on schedule mode with enough cron capacity.
Choosing a connector: selection criteria
There is no single right connector for every ERP and store. Score candidates against these criteria instead:
- Coverage of your flows. Check every row in the table above, including B2B pricing, partial shipments and returns.
- Version support. Confirmed compatibility with your Magento version and the next one, and with your ERP version and edition.
- Architecture. In-Magento module, external middleware or out-of-process app. Decide which you want before comparing products.
- Queueing and retries. Does it queue messages, retry with backoff and expose failures?
- Monitoring. Logs your team can read, alerts, and a way to replay failed messages.
- Mapping flexibility. Custom fields, custom order types and multiple stores or warehouses without code changes.
- Performance. Uses bulk or async endpoints for large updates rather than one call per item.
- Security. Dedicated integration credentials with least privilege, encrypted secrets.
- Vendor health and exit. Release history, support terms, and what happens to your data and mappings if you leave.
Ask each vendor to demonstrate your three hardest scenarios on a test system, not their standard demo.
B2B considerations
B2B stores push more through the ERP: company accounts, credit limits, customer-specific catalogs and prices, quotes and invoices. Decide early whether customer-specific prices are copied into Magento or looked up live, because that choice shapes the whole design. Our B2B ecommerce guide covers the wider requirements.
A sensible rollout
- Agree data ownership and the data-flow table with finance, operations and ecommerce.
- Build orders first, then shipments and stock, then prices, then customers.
- Test with real historical baskets, including the awkward ones.
- Run in parallel with manual checks for a short period before switching off old processes.
- Hand over monitoring with clear ownership of failed messages.
FAQ
Should stock sync be real time?
Near real time for fast-moving or low-stock items, with a full reconcile nightly. True real-time lookups at checkout add a dependency on ERP uptime.
Can we integrate without changing Magento code?
Often, yes: middleware or an out-of-process app can use the standard REST APIs and events. Custom fields or custom order data may still need a small module.
Which data should never sync both ways?
Stock and prices. Give them one owner, usually the ERP, to avoid overwrites.
Getting help
Mistri scopes and builds ERP integrations using the patterns above. Our Adobe Commerce development team handles the store side and integration design, and our Magento extension development service covers custom connectors and the modules they need.
Sources
Adobe Developer: REST bulk endpoints; Adobe Developer: Asynchronous web endpoints; Adobe Developer: Integration starter kit; Adobe Developer: Webhooks (synchronous vs asynchronous guidance). Checked November 2026.
