Magento integration with your ERP, warehouse and suppliers

What Magento is and who runs it

Magento comes in two editions from Adobe: Magento Open Source, free to install, and Adobe Commerce, licensed, with the B2B modules. Both run as a PHP application on a server the merchant, an agency or a host controls. That makes Magento different from a hosted platform for an integration: the API limits are set by your hosting, extensions can change what an endpoint returns, and the version on your server is your decision.

Adobe ships minor versions on a fixed calendar. 2.4.9 came out on May 12, 2026. Regular support for 2.4.6 ended on August 11, 2026, for 2.4.7 it ends on May 31, 2027 and for 2.4.8 on May 31, 2028. A store several versions behind still has the REST API, but not the features added since, such as the event and webhook modules of 2.4.4.

What connects to Magento

Magento owns the order and the storefront. The ERP is the system of record for items, prices and stock, a PIM often for product content. These are the flows we build as part of an e-commerce ERP integration:

An order has two numbers. entity_id is the internal key used in every endpoint, increment_id is the number the customer sees, such as 000100482. The ERP gets the increment_id as its reference and the integration keeps both. A shipment goes back with its tracks, carrier code and tracking number, and only then does Magento clear the reservation for that order.

How Magento exposes data

REST, GraphQL and the bulk API

Magento has a REST API and a GraphQL API. Adobe presents GraphQL as the base for headless storefronts and mobile apps; the integration works on REST, which covers the back-office side: orders, invoices, shipments, credit memos and source items. A list query takes searchCriteria. Without a pageSize, Magento returns every match in one response, so the integration always sets one:

GET /rest/V1/orders?searchCriteria[filter_groups][0][filters][0][field]=updated_at
    &searchCriteria[filter_groups][0][filters][0][value]=2026-10-03 06:00:00
    &searchCriteria[filter_groups][0][filters][0][condition_type]=gt
    &searchCriteria[pageSize]=100&searchCriteria[currentPage]=1
Authorization: OAuth oauth_consumer_key="...", oauth_signature_method="HMAC-SHA256", ...

For large writes there is the asynchronous bulk API: the same endpoint under /async/bulk/, which returns a bulk_uuid at once and hands the work to the async.operations.all consumer through a message queue. The integration then reads the status of each operation from the bulk status endpoint, so a rejected row is reported with its SKU instead of disappearing.

Authentication

An integration created in the admin gets a consumer key, consumer secret, access token and access token secret, and signs each call with OAuth 1.0a and HMAC-SHA256. Since 2.4.4 that access token cannot be used as a standalone bearer token unless an administrator turns the option back on. An admin token is the alternative and lasts four hours by default. The integration gets its own integration with access to the resources its flows use, never an administrator account.

Input limits, not rate limits

Adobe documents no general request rate limit for the REST API. It has input limits, disabled by default. When a store switches them on:

Worked through for a stock write of 20,000 source items on a store with input limits on: synchronous calls take 20,000 / 20 = 1,000 requests, the bulk endpoint 20,000 / 5,000 = 4. Reading 60,000 products at 300 per page is 200 pages. Without input limits the numbers come from your server: memory, PHP workers and the queue consumers. We measure them on your store, run the integration with fewer workers than the storefront needs to stay fast, and move large writes to the bulk API. Adobe's API security page describes the settings.

Where a Magento integration gets stuck

Sources, reservations and salable quantity

With multi-source inventory, stock lives per source: a warehouse, a store, a supplier. The ERP writes quantity and status per sku and source_code. Magento does not sell that number. It adds the sources of a stock, subtracts the out-of-stock threshold, and subtracts reservations: an order creates a reservation, and the reservation clears when the shipment is created in Magento.

The trap is the ERP number. Most ERPs report free stock, which already excludes orders they have received. If the integration writes that number to the source, an order that is in the ERP but not yet shipped in Magento is subtracted twice: 17 - 3 - 2 = 12 where 15 can be sold. The integration writes the quantity that matches Magento's formula, physical stock minus the ERP's commitments for orders that did not come from this store. Bundle and grouped products have to stay on the default source. See which stock counts.

Attribute sets, option IDs and configurable products

A product belongs to an attribute set, and an option such as color "Black" is stored as an option ID that differs per installation: 58 on one store, 169 on its staging copy. The integration resolves options by label per store and keeps the mapping, instead of carrying IDs from one environment to another. A configurable product needs its options defined per attribute and its children linked one childSku per call, so a new size range is a series of calls in a fixed order.

Prices per customer group and B2B

A tier price has sku, price, price_type (fixed or discount), website_id, customer_group and quantity. Price scope is global by default, so a price per website needs the scope switched to website first. ERP price groups map to customer groups. On Adobe Commerce a shared catalog adds its own customer group, and a company has a credit limit in credit_limit. An ERP with more price groups than you want customer groups needs a decision per group; customer-specific pricing describes the options.

Systems we integrate with Magento

Each ERP stores items, stock and prices in its own way, so each pair has its own page:

• Magento NetSuite integration: configurable products against matrix items, sources against NetSuite locations, customer groups against price levels.
• Magento Business Central integration: item variants, posting groups, and a stock total that drops when the shipment is posted.
• Magento SAP integration: price lists and special prices against tier prices and customer groups.

Magento EDI integration covers orders from retail trading partners. The system side is on NetSuite, Business Central and SAP Business One.

We build the integration for a fixed price, then host it, monitor it and adjust it when you upgrade Magento or an extension changes an endpoint, for a monthly fee. Before go-live it runs as a dry run that writes nothing: you see per product which source quantity and price it would set. Every integration comes with a dashboard, logs and a per-run diff. Tell us which version and edition you run.