Magento B2B integrations scale when you match the sync pattern to each data type instead of picking one global setting. Orders and inventory belong on near-real-time events or a message queue. Catalog and reporting belong on scheduled batch. The mechanics that make this hold up are async bulk APIs, RabbitMQ consumers, inventory reservations, and idempotent writes. Miss those and it breaks under load.
We are Bemeir, a Brooklyn ecommerce agency and the first US-based Hyva Gold Partner, with more than a decade of B2B work on Magento and Adobe Commerce. This is a technical guide to the integration patterns themselves: how they behave at volume, the native Magento primitives that carry them, and the anti-patterns we get called in to undo. It is written for the technical lead and the merchandising lead who have to live with the result.
Match the pattern to the data
The first mistake teams make is choosing one integration style for everything. Real production integrations use several patterns at once, each assigned to the data whose volatility and volume fit it. Here is how the options compare.
| Pattern | When to use | How it scales | Main pitfall |
|---|---|---|---|
| Point-to-point (direct API) | One ERP, narrow scope, low volume | Poorly, every new system is a new bespoke link | Tight coupling, no central retry or monitoring |
| Middleware / ESB | Several back-office systems | Well, one hub routes, maps, and queues | Build cost, can become a bottleneck if under-provisioned |
| iPaaS (Celigo, Boomi, Jitterbit, Workato) | Standard connectors exist, limited dev capacity | Well, managed retries and dashboards | Per-flow cost, connector limits on B2B edge cases |
| Event-driven, out-of-process (Adobe I/O Events plus App Builder) | Adobe Commerce, want decoupling and near-real-time | Best for scale, runs outside the core app | Adobe Commerce only, eventual-consistency semantics |
| Async message queue (RabbitMQ, SQS, Kafka) | High volume, downstream may be slow | Best, back-pressure absorbs ERP downtime | Needs worker management and dead-letter design |
| Scheduled batch | Historical data, catalog refresh, reporting | Efficient for large one-pass datasets | Staleness equals an oversell window |
A useful rule of thumb: match cadence to volatility per data domain, not one interval across the board. A store doing thirty to eighty orders a day rarely needs second-by-second inventory precision, especially in B2B where an approval workflow already sits between cart and fulfillment. Inventory and pricing want near-real-time. A product-description refresh is fine on a nightly job.
The Magento mechanics that make integration scale
The architecture diagram is the easy part. What separates an integration that holds up from one that falls over is whether it uses the platform’s native primitives correctly. These are the ones that matter for Magento and Adobe Commerce at B2B volume.
Three tiers of REST endpoints. Magento exposes synchronous, asynchronous, and bulk REST. Synchronous calls block until the work finishes. Asynchronous calls queue the request and return a bulk_uuid immediately, so the caller does not wait. Bulk calls accept an array and split it into per-entity messages on the queue. The performance difference is real: independent testing has shown bulk operations running dramatically faster than synchronous ones at a thousand items, while single-item payloads are actually more efficient sent synchronously. The takeaway is to send big jobs through the async and bulk endpoints and keep tiny one-record calls synchronous.
RabbitMQ is not optional for async. The async and bulk endpoints depend on a message broker. The current Magento line runs RabbitMQ with quorum queues, and the consumers that drain those queues are PHP worker processes you keep alive under a process supervisor. If those consumers are not running or not monitored, async requests pile up silently and nothing tells the storefront.
Reservations are your native oversell defense. Multi-Source Inventory computes a salable quantity as the sum of source quantities minus reservations minus the out-of-stock threshold. A reservation is a temporary hold placed when an order is submitted, cleared and deducted when the shipment happens. This decouples “sold” from “physically shipped,” which is exactly what you need when a POS register and the web store draw from the same stock. Adobe’s documentation on salable quantity and reservations explains the mechanism, and understanding it is what lets you set a sync cadence that keeps the number honest.
Events versus webhooks is a real decision. On Adobe Commerce, Adobe I/O Events fire asynchronously when something happens, an order is placed, stock changes, a customer is created, and an App Builder application then pulls the detail and pushes it to the ERP or CRM. Webhooks, by contrast, are synchronous: they call an external URL inline and block the Commerce action until the response comes back. Adobe’s own guidance is to prefer async events by default and reserve synchronous webhooks for the cases where you must compute, validate, or write back inline, such as a live tax calculation or a credit check at checkout.
Extension attributes are how you attach ERP and CRM fields, external IDs, credit terms, and the like, to core entities in API payloads without editing core code. Getting this right keeps your integration upgrade-safe.
ERP, CRM, and POS each want a different pattern
The three back-office systems a B2B merchant integrates are not interchangeable, and treating them the same is where a lot of designs go wrong.
ERP is the system of record for money and stock. Orders flow down from Magento to the ERP, and the correct pattern is an asynchronous event or a queue on order placement, never a synchronous call inside checkout. Inventory and pricing flow up from the ERP to Magento in near-real-time, writing to the MSI source quantities so reservations and salable quantity absorb the race conditions. The governing rule is to define which system owns each object: the ERP owns price, stock, and credit, Magento owns the cart and the web customer.
CRM systems such as Salesforce, Dynamics, or HubSpot map company accounts to CRM accounts and buyers to contacts. A B2B quote request and its negotiation sync to a CRM opportunity, and order history pushes over for a full account view. This data is far less volatile than stock, so an event-driven or even scheduled pattern is fine. None of it is checkout-critical.
POS and omnichannel carry the highest oversell exposure because a register and the website can sell the same unit within seconds of each other. The pattern here is a shared salable quantity: the POS is modeled as a source or stock inside MSI, both channels reserve against the same pool, and the cadence has to be near-real-time. Customer identity should unify too, so an in-store buyer and a web buyer resolve to the same company and pricing.
What makes an integration actually idempotent
Everyone says the word idempotent. Fewer builds actually implement it. At B2B volume, these are the mechanics that keep a retried message from creating a duplicate order or a double invoice.
- Natural-key upserts. Use the order increment ID, the SKU, or the external ERP ID as an idempotency key, and upsert on conflict. A retried “create order” then updates the existing record instead of creating a second one. Deduplicate bulk operations on the returned UUID.
- Retries with backoff. Automatic retry handles transient failures, and exponential backoff keeps you from hammering an ERP that is already struggling to recover.
- Dead-letter queues. Poison messages that will never succeed get moved aside for human review rather than blocking the queue behind them.
- Reconciliation as a scheduled job. A recurring compare of stock, price, and order status detects drift. A pricing mismatch should fail the sync and alert someone before a customer sees the wrong number.
- Delta over full sync. Sync by modified timestamp or changelog for routine runs. A full sync is a periodic safety net, not something you run every cycle.
- Respect rate limits. Queue plus controlled consumer concurrency is your throttle against ERP and CRM API limits.
Anti-patterns we are called in to fix
Most rescue projects share the same handful of root causes.
A synchronous ERP call inside checkout ties order placement to the ERP’s uptime and latency, so an ERP hiccup becomes a lost sale. No reconciliation means stock, price, and status drift silently until a customer complains. Tight point-to-point coupling at scale is brittle and impossible to monitor as connections multiply. Full catalog sync every run wastes cycles and trips rate limits when a delta would do. Stale batch inventory turns every gap between syncs into an oversell window. And assuming Magento Open Source has outbound webhooks is a dead end, because it does not, a distinction we cover next.
Open Source versus Adobe Commerce changes your options
This split catches teams off guard. Magento Open Source has the internal events and observers system, which runs in-process and does not make outbound HTTP calls. Native outbound webhooks and Adobe I/O Events are Adobe Commerce features. If your architecture assumes the platform will push events to your integration layer, that assumption only holds on Adobe Commerce or through an App Builder application. On Open Source you design around the API and a middleware layer that polls or receives pushes from your side. Knowing this before you draw the architecture saves a painful redesign later.
How Bemeir builds these
We assign a pattern per data domain, near-real-time events and queues for orders and inventory, scheduled batch for catalog, and we treat reconciliation and dead-letter handling as first-class parts of the build rather than things bolted on after go-live. Our technology partner ecosystem spans more than sixty integrations, so we can recommend an iPaaS, a prebuilt connector, or a custom App Builder integration based on your systems and volume rather than a reseller relationship. Performance is part of the same job: a B2B store carrying heavy catalog and pricing logic still has to feel fast, which is why we pair integration work with Hyva frontend development.
The pattern discipline is the same whether the storefront runs on Adobe Commerce, Shopify Plus, BigCommerce, or Shopware. The platform changes the primitives, not the principles. You can learn more about our team on the about Bemeir page.
Frequently Asked Questions
Should B2B inventory sync in real time or batch?
Near-real-time for inventory and pricing through an event or a queue, and batch for catalog and reporting. Match the cadence to how fast the data changes and how much oversell you can tolerate. B2B approval workflows mean you rarely need second-by-second stock precision, but you do need sub-hour cadence to keep the oversell window small.
Webhooks or Adobe I/O Events for ERP integration?
Prefer asynchronous I/O Events by default because they decouple your integration from the Commerce action. Use synchronous webhooks only when Commerce must compute, validate, or write back inline, such as a live tax calculation or a credit check. Note that both are Adobe Commerce capabilities, not Magento Open Source.
How do I stop overselling when POS and web share stock?
Model the POS as a source inside Multi-Source Inventory so both channels draw from one salable quantity, use reservations to hold stock on order submission, and set an out-of-stock threshold as a buffer. Keep the reindex and sync cadence sub-hourly so the number stays accurate.
What actually makes an integration idempotent?
A natural-key upsert. Use the order ID, SKU, or external ERP ID as the key and update on conflict instead of inserting, so a retried message never double-creates a record. Deduplicate bulk operations on the UUID the async endpoint returns.
Do I need middleware or iPaaS, or can I integrate directly?
Direct point-to-point is fine for a single ERP with narrow scope. Add a middleware, iPaaS, or event-driven hub once you have two or more back-office systems, because point-to-point coupling grows brittle and unmonitorable as the number of connections climbs.
How do I move large catalogs or order batches without timeouts?
Use the bulk asynchronous REST endpoints over RabbitMQ with worker consumers. Bulk operations run far faster than synchronous ones at scale, though single-item calls are more efficient sent synchronously, so reserve async and bulk for genuinely large jobs.
