Magento NetSuite integration

What moves between Magento and NetSuite

Magento holds the catalog as customers see it and captures the order. NetSuite holds the item master, the stock and the books. The integration covers eight groups of fields.

A Magento order has two identifiers. entity_id is the number in every API path, such as POST /V1/order/3/ship. increment_id is the number the customer sees, such as 000000003. NetSuite gets the increment_id as external ID and PO reference; the integration keeps the entity_id to post the shipment back.

Which system owns what

Salable quantity is the one row where Magento calculates and NetSuite only supplies. That split is where most stock differences in this pair come from.

What Magento and NetSuite store differently

Configurable products and matrix items

A NetSuite matrix is one parent and up to 2,000 child items. In Magento the parent is a configurable product and every child is a separate simple product with its own SKU and its own stock. The link is made one child at a time: POST /V1/configurable-products/TS/child accepts a single childSku.

A shirt in 6 sizes and 8 colors is 48 children. Creating it takes 48 simple products, 1 configurable product, 2 option calls for size and color, and 48 link calls: 99 requests for one style. A season of 200 styles is 19,800 requests. The simple products go through the bulk endpoint in batches; the link calls cannot be batched and run from a queue. More on the modeling in variant mapping.

Kits and bundles

A NetSuite kit is one line on the sales order that breaks into components at fulfillment. A Magento bundle arrives as a parent order item plus child items that point to it through parent_item_id. The mapping needs an explosion rule: which line carries the price, and whether NetSuite receives the kit or the components. Adobe documents one more constraint: bundle and grouped products do not support multiple sources and have to sit on the default source.

Stock: source quantity and salable quantity

Magento's inventory has sources (where stock lies), stocks (which sources serve a website) and reservations. The salable quantity is the sum of the source quantities for a stock, minus the out-of-stock threshold, minus open reservations. A reservation is created when the order is placed and cleared when the order ships.

NetSuite's Available is On Hand minus Committed. An order that has been imported is committed in NetSuite and reserved in Magento at the same time. Write Available to the source and that order is subtracted twice: 20 on hand, 4 ordered, 16 written, 12 salable. The integration writes On Hand per location to POST /V1/inventory/source-items with sku, source_code and quantity, and posts the shipment before the next stock write, so the reservation and the source deduction line up. Which stock counts covers the general rule.

Price levels, customer groups and tier prices

A NetSuite price is a cell in a grid of item, price level, quantity break and currency. A Magento tier price is a row:

{
  "prices": [
    {
      "sku": "TS-BLK-M",
      "price": 31.50,
      "price_type": "fixed",
      "website_id": 1,
      "customer_group": "Wholesale",
      "quantity": 10
    }
  ]
}

Three things have to be set before this works. Each price level needs a customer group. Magento's price scope is global by default, so a price per currency needs the scope switched to Website and one website per currency. And in NetSuite the Quantity Pricing feature has to be on, since its REST item record leaves the quantity pricing fields out and the price breaks come through SuiteQL. See customer-specific pricing for prices per account.

Addresses

Magento stores the street as an array of lines, "street": ["Industrieweg 12", "Unit 4"], with company, postcode and a two-letter country_id. NetSuite has addr1, addr2 and addr3 next to addressee and attention. Company goes to addressee, the contact name to attention, each street line to its own field. A carrier label that prints 35 characters per line still cuts a long company name, so the integration checks lengths before the order reaches the warehouse.

The technical reality of this pair

The two APIs are limited in opposite ways. NetSuite counts concurrent requests. For Magento on your own server or on Adobe's cloud infrastructure, Adobe documents no general rate limit on the REST API: the maximum is what the server can handle, and an integration that reads too much at once slows the storefront.

Prices, worked through. 8,000 SKUs with 3 price levels and 4 quantity breaks is 96,000 tier price rows. With input limits on, a synchronous request carries 20 rows: 4,800 requests. The asynchronous bulk endpoint carries 5,000 rows: 20 requests. On the NetSuite side the same rows are 96 SuiteQL pages in one concurrency slot. After the first load only changed rows move.

The bulk endpoint depends on a consumer. A bulk request returns a bulk_uuid at once and the work happens in the message queue. If the consumer async.operations.all is not running, every operation stays at status 4, Open, and nothing reports an error. The integration reads GET /V1/bulk/{uuid}/status after each batch and raises an alert when operations stay open.

A search without a page size returns everything. Magento's documentation says so in one line. A product search without pageSize on a catalog of 60,000 SKUs is one response with 60,000 products. Every read the integration makes is paged.

Orders, worked through. On Open Source the integration polls GET /V1/orders filtered on updated_at. At one poll every 2 minutes that is 720 light requests a day. Writing to NetSuite is the slower side: at 3 seconds per sales order and 2 of 5 concurrency slots, 40 orders a minute. The numbers behind that are in NetSuite concurrency limits and on the NetSuite page.

Where standard connectors stop

Packaged connectors and iPaaS templates for this pair document their own limits.

• Tier pricing in one shape. The common model is website by customer group by price level. It is documented as unsupported for bundle products, and it cannot run together with attribute sync to all store views.
• Locations to sources, one to one or many to one. One NetSuite location feeding two Magento sources, or an allocation rule per website, is outside the settings.
• Quantity pricing as a precondition. Tier prices sync only when NetSuite's Quantity Pricing feature is enabled; a price grid kept in custom fields or custom records is outside the model.

A built integration has none of these as fixed points: the price model, the source allocation and the kit explosion rule are written to how your account and your store work. The technical comparison is in custom integration vs iPaaS.

When it goes wrong

An order that keeps failing is kept with its original payload and can be sent again once the cause is fixed. A reconciliation run compares Magento orders of the last days against NetSuite external IDs, so an order missed by a poll or an event still arrives.

Before go-live the integration runs as a dry run: it reads both sides and shows the products, prices and orders it would write, without writing. You approve that result, and from then on every run leaves a diff per record in the dashboard. We host and monitor it as part of an e-commerce ERP integration, and we fix it when Adobe or Oracle changes an interface. The Magento page covers the platform side. Sibling pages: Shopify NetSuite integration, WooCommerce NetSuite integration and BigCommerce NetSuite integration. Tell us which Magento version and NetSuite edition you run.