Ecommerce ERP integration, built around the rules your business runs on

Three ways to connect a store to an ERP

There are three: a packaged connector, an iPaaS platform, and an integration built for your systems. The third comes in two forms: built and handed over, or built and run for you. We do the last one.

The row that separates them is the last one. Shopify releases a new API version every three months and supports each stable version for at least twelve months. A request to a version that is no longer supported is answered by the oldest supported version, with whatever fields that version has. The REST Admin API has been a legacy API since October 1, 2024, and new public apps have had to use GraphQL since April 1, 2025. An integration built on REST runs on an API that Shopify no longer develops. The question to ask of any option is who follows these changes and who does the work.

The second difference shows with volume. An integration that fails on 1 order in 50 is workable at 20 orders a day: 20 times 7 divided by 50 is about 3 orders a week, fixed by hand. At 200 orders a day it is 4 a day. On a peak day with 2,000 orders it is 40, on the day nobody has time. What decides whether an integration holds at volume is what it does with the order that fails. The comparison of a custom integration and an iPaaS goes through the technical differences.

What moves, and who owns it

Each piece of data has one owner. Every other system receives it.

Each row is a flow with its own page: stock and availability, pricing and customer terms, orders, customers and shipping and product data. Buyers who order from inside a procurement system are covered under PunchOut. All five are on the integrations overview.

Two decisions belong to the order flow and are made once. The first is the landing record: in NetSuite a store order becomes a sales order, a cash sale or an invoice, and a refund becomes a cash refund, a credit memo or a customer refund. The second is tax. When the store sends its tax lines and the ERP also calculates tax on the order, every transaction is recorded with the wrong amount. One side calculates and the other accepts the result.

The mapping is the work

Two systems rarely store the same thing the same way. This is an order as the store sends it:

{
  "name": "#10482",
  "customer": { "email": "ap@example.com" },
  "shipping_address": {
    "company": "Example Mechanical Supply of Northern Nevada LLC",
    "address1": "2180 Industrial Way Ste 104",
    "province_code": "NV",
    "zip": "89502-5981",
    "country_code": "US"
  },
  "total_tax": "38.61",
  "taxes_included": false
}

Five things in this fragment have to be decided before it becomes an ERP order.

The customer match is a chain, in a fixed order: the customer number when the store knows it, then the company's tax or registration number, then the company's email address, then the contact's email address, and only then a new customer. A translation table between store customer and ERP customer number is kept in the integration, and someone has to own it. The notes on duplicate customers and orders and address field mapping cover both in detail.

Records that fail validation go on a list with the reason. They are not skipped. A skipped order shows up weeks later as a customer complaint; a listed one is fixed the same morning.

Where connectors stop

Standard connectors and iPaaS templates document their own limits. These come from their product documentation:

• One price level at a time. The item export carries one price level for the selling price and one for the compare-at price. Wholesale, contract and tiered prices need custom fields that a script in the ERP keeps filled.
• Location mapping without rules. ERP locations map one to one, or several into one store location. Which location fulfills first, or how much of a location is reserved for a channel, is not a setting.
• Unmapped items are skipped. An item without a mapping record is left out of the inventory sync and no error is raised.
• No delivery dates. The inventory flow carries a quantity. An expected or promised date has no field.
• Templates are unmanaged. In the catalog of one large iPaaS vendor, 16 pair integrations are managed apps and 192 are templates, counted on September 30, 2026. A template receives no fixes and no new functionality after installation.

None of this is a defect. A product that serves many accounts with one codebase stops at the shape most of them share. The work that remains is the part that is specific to your account, and that is what we build.

What happens when it fails

API limits are reached on the busiest day, because that is when every integration on the account sends the most requests. The limits are published:

Sources: Shopify webhook troubleshooting, NetSuite concurrency governance and Business Central operational limits, checked on October 3, 2026.

The first row is the one that breaks quietly. An integration that creates the ERP order inside the webhook handler answers late when the ERP is slow. Shopify counts a failure and sends the order again. After 8 failed retries the webhook subscription is removed, and from then on no orders arrive and nothing reports an error.

The design that holds has four parts:

1. A queue. The store gets 200 OK at once. The ERP is called from the queue, at the pace it accepts.
2. Retries with growing pauses. A 429 or a timeout is retried after seconds, then minutes.
3. Idempotent writes. Every order carries the store's order ID as its external ID. Before a retry, the integration checks whether the order already exists.
4. A dead-letter queue and reconciliation. What still fails stays, with its original payload. A scheduled comparison of store orders against ERP orders catches what never arrived.

In the diagram, attempt 2 times out after NetSuite has created the sales order. A blind third attempt creates a second one, and the customer is shipped and invoiced twice. The lookup on external ID 10482 finds SO-20418 and closes the order. The notes on API throttling and backoff and what happens when a sync fails describe each step.

What you get

We build the integration to your systems and rules, host it and run it. The build has a fixed price and running it has a monthly fee. What is in the service:

• Hosting and monitoring. The integration runs with us. We see a failing run before your customer service does.
• Changes on either side. When an API version ends, a field is renamed or a supplier changes a file, we change the integration.
• A dashboard with a login. Logs per run, the records that failed, and the diff of what each run changed.
• Dry run and approval. A run can calculate everything and write nothing. Changes can wait for your approval, per connection.
• Exclusions and overrides. Products or customers with a manual arrangement are left alone.

When an existing integration or script is being replaced, the new flow first runs next to the old one without writing. Both process the same data and the differences are logged. After that period you know what the old integration did, including the rules nobody wrote down. The switch is made per flow. See replacing an integration and how an integration works.

ERPs we connect

• NetSuite: REST and SOAP web services, with the account concurrency limit of 5 to 20 requests shared by every integration. Pairs: Shopify, Magento, BigCommerce and WooCommerce.
• Business Central: OData API with 6,000 requests per 5 minutes per user. Pairs: Shopify and Magento.
• SAP Business One: price lists and special prices per business partner with date ranges. Pairs: Shopify and Magento.
• Acumatica: the license tier sets the number of concurrent API requests and the requests per minute.
• Sage Intacct and Odoo.

For a store on Shopify, the Shopify ERP integration page covers the platform side. Trading partners that require X12 documents are covered under EDI integration.

Tell us which store and which ERP you run, and which flow hurts most. You get a concrete answer.