Shopify logo

Shopify + Acumatica Integration

Stock items, inventory, and pricing flow out of Acumatica into Shopify. Orders and customers flow back as sales orders and business accounts. Acumatica stays the system of record for inventory and finance; Shopify never posts to your GL.

mode:
Bidirectional
latency:
Near real-time
maturity:
Production-tested

what syncs

What syncs, which way, and how fast

Every row is a real data flow with a real trigger. The frequency column is what you should expect in production, not a best case.

Products

dir:
Acumatica → Shopify
frequency:
Every 15 min

Inventory ID is the join key. Only stock items flagged for the storefront are pushed, so the full Acumatica item master does not leak into the catalogue.

Inventory

dir:
Acumatica → Shopify
frequency:
Every 5 min

Quantity available, not raw on-hand. Each Shopify location maps to one Acumatica warehouse, so allocated stock never shows as sellable.

Pricing

dir:
Acumatica → Shopify
frequency:
Every 15 min

Default sales prices to Shopify price, customer price classes to B2B catalogues. Promotional pricing stays in Shopify to avoid a two-system tug of war.

Orders

dir:
Shopify → Acumatica
frequency:
Near real-time (webhook)

Creates an Acumatica sales order. Shopify order name lands in the Customer Order field so support can search either system by the same reference.

Customers

dir:
Bidirectional
frequency:
Near real-time

B2C checkouts post against a single generic web account. B2B accounts map one-to-one to business accounts with their terms and credit limit.

Fulfillment

dir:
Acumatica → Shopify
frequency:
Near real-time

A confirmed shipment closes the Shopify fulfillment and pushes the tracking number, which triggers the shipping notification.

architecture

How it actually works

Acumatica is a cloud ERP with a genuinely good contract-based REST API, so the plumbing is simpler than an on-premise build. The design questions are where the native Retail edition connector stops, and how to stay inside license-based API limits.

  1. Shopify Admin API + webhooks

    Order, customer, and fulfillment events fire webhooks. We verify the HMAC signature and queue the payload rather than processing inline, so a slow ERP call never causes Shopify to mark the endpoint as failing.

  2. Native connector (Retail edition)

    Acumatica ships a first-party Shopify connector in its Retail edition. When your license includes it and your requirements are standard, we configure it rather than rebuild it. That evaluation happens in discovery, not after a build.

  3. Contract-based REST endpoint

    The supported integration surface. Entities such as StockItem, SalesOrder, Customer, and Shipment sit behind a versioned endpoint contract, so an Acumatica upgrade does not silently change the schema underneath the integration. Custom fields go through an endpoint extension rather than ad hoc queries.

  4. Generic inquiries for bulk reads

    Inventory and price reads come from generic inquiries rather than record-by-record gets, which is the difference between a sync that fits inside the API allowance and one that exhausts it. Push notifications flag changed records where polling would waste requests.

  5. License-aware scheduler

    Acumatica caps API usage by license tier, and the cap is shared with every other integration you run. Sessions are reused rather than re-established per call, and batch work is scheduled so integration traffic never crowds out the people working in Acumatica.

failure modes

What breaks, and what happens when it does

Every integration fails eventually. The difference between a good one and a bad one is whether it fails safely and tells you.

  • License-based API throttling

    The sync works in testing, then slows or errors once real order volume and a second integration arrive.

    handling

    Acumatica limits API usage by license tier, and the allowance is shared across everything that talks to the instance. We budget requests per object, reuse sessions instead of logging in per call, move bulk reads to generic inquiries, and back off on throttled responses rather than hammering the endpoint.

  • Tax recalculation mismatch

    Shopify order totals and Acumatica invoice totals differ by cents, and finance refuses to sign off.

    handling

    Acumatica wants to calculate tax from its own tax zones, which almost matches what Shopify charged. We treat Shopify as authoritative for tax collected at checkout, pass it through as a tax override instead of letting Acumatica recalculate, then reconcile rounding at line level so the invoice ties to the payout.

  • Multi-warehouse oversell

    Two customers buy the last unit within the same sync window, or stock allocated to a large B2B order shows as sellable online.

    handling

    We sync quantity available rather than on-hand, with each Shopify location mapped to one Acumatica warehouse and a configurable buffer on fast movers. Oversells are reduced, not eliminated: any polling integration has a window, and we say that up front rather than promising zero.

  • Customer price class mismatch

    A wholesale buyer logs in and sees retail pricing, or a retail shopper glimpses a contract price.

    handling

    Price classes stay in Acumatica and map to Shopify B2B catalogues per company, resolved from the business account rather than a discount code. Each class mapping is explicit and tested, because a leaked contract price is a commercial problem, not a cosmetic one.

  • Business account bloat from guest checkouts

    Thousands of one-time B2C buyers arrive as individual business accounts and the customer list becomes unusable.

    handling

    B2C checkouts consolidate behind a single generic web account, and only genuine B2B customers get individual business accounts with terms. This is decided before the first sync, because unpicking thousands of junk accounts afterwards is slow, manual work.

  • Upgrade and customisation drift

    An Acumatica upgrade or a new customisation lands and a field quietly stops syncing.

    handling

    The integration pins a specific endpoint version, which is exactly what contract-based endpoints are for, and custom fields go through a named endpoint extension. Upgrades are tested against a sandbox tenant before production, and unmapped fields report to a reconciliation digest instead of failing silently.

field mapping

A real slice of the mapping

This is an abridged Order → Acumatica SalesOrder mapping, shown so you can sanity-check it against your own system.

Order → Acumatica SalesOrder

shopify → acumatica

  • order.nameSalesOrder.CustomerOrder

    Searchable in both systems

  • order.idSalesOrder.Description

    Numeric id for support lookups

  • line_item.skuDetails.InventoryID
  • line_item.quantityDetails.OrderQty
  • line_item.priceDetails.UnitPrice

    Tax-exclusive

  • location_idDetails.WarehouseID

    Via location map

  • customer.emailCustomer.MainContact.Email
  • total_taxSalesOrder tax override

    Passed through, not recalculated

Representative defaults from live builds. Your endpoint version and custom fields change the mapping: price classes and warehouse maps are decided during the audit.

implementation

Timeline and cost

typical duration

6 to 10 weeks

included in scope

  • Discovery and field-level mapping document
  • Native connector evaluation against your edition and scope
  • Six objects bidirectional with the matrix above
  • Idempotent queue, retry, and dead-letter handling
  • Monitoring dashboard and failure alerting
  • Two weeks of hypercare and a handover runbook

what moves it up

  • Multiple companies, branches, or more than three warehouses
  • Customer price classes with per-company B2B catalogues
  • Historical order and customer backfill
  • Heavily customised Acumatica with endpoint extensions
  • Additional endpoints such as a 3PL or marketplace

questions

Questions buyers actually ask

Does Acumatica have a native Shopify connector?

Yes. Acumatica ships a first-party Shopify connector as part of its Retail edition, and it is genuinely usable: on the common path, items, inventory, prices, orders, customers, and shipments sync with configuration rather than code. The honest caveat is that it is edition-dependent, so check whether your license actually includes it before assuming it is free. Where projects really live is the mapping the connector cannot decide for you: customer price classes, multi-warehouse availability rules, and custom fields. Evaluate the connector first and pay only for the gap.

Do we need a VPN or on-premise tunnel like other ERPs?

Normally no, and this is one of the quiet advantages of Acumatica. Most instances are cloud-hosted, and the contract-based REST API is reachable over HTTPS with OAuth, so there is no site-to-site VPN, no reverse tunnel, and no firewall negotiation with IT. If your instance is self-hosted on your own infrastructure the same API applies, but reachability has to be designed deliberately, usually with an outbound-only tunnel rather than an inbound port to the ERP host.

What does contract-based API actually mean, and why should we care?

It means the integration talks to a versioned endpoint contract rather than to whatever the current screens happen to expose. Entities such as StockItem, SalesOrder, Customer, and Shipment sit behind a named endpoint version, and an Acumatica upgrade does not silently change that schema underneath you. This is why Acumatica integrations age better than table-level or screen-driven builds: upgrade risk is contained, and custom fields are added through an endpoint extension you control rather than ad hoc workarounds.

Are there API rate limits we will hit?

Yes, and they are commercial rather than purely technical: Acumatica limits API usage based on your license tier, and the allowance is shared by every integration talking to the instance. The exact numbers depend on your license, so we treat the budget as a design input rather than quoting one figure here. The practical consequences are reusing sessions instead of logging in per call, moving bulk reads to generic inquiries, and scheduling heavy jobs so the integration never crowds out your own users.

How does multi-warehouse inventory sync work?

Each Shopify location maps explicitly to one Acumatica warehouse, and we sync quantity available rather than raw on-hand so stock allocated to other orders is never offered twice. That mapping is agreed before build, because changing it afterwards means re-syncing availability across the whole catalogue. On fast-moving lines we set a small buffer instead of pretending a polling sync has no window.

Can our B2B customers see their contract pricing on Shopify?

Yes. Customer price classes stay in Acumatica and map to Shopify B2B catalogues per company, so a logged-in wholesale buyer sees the price resolved from their business account, not from a discount code. This needs Shopify Plus for the B2B objects, and it is the single most common thing that extends the scope and timeline of an Acumatica project. Retail shoppers keep seeing the default price list either way.

What happens to orders if Acumatica is unreachable?

Shopify keeps taking orders. Each order webhook lands in a durable queue with the Shopify order id as an idempotency key, so if Acumatica is down for maintenance or an upgrade window the messages wait and replay in order once it answers. Nothing is lost, no order is created twice, and nobody re-keys orders by hand. We also never post to your general ledger: orders create sales orders and business accounts, and your existing posting rules handle the accounting.

shopify + acumatica

Find out where the native connector stops

Send us your Acumatica version, edition, warehouse count, and order volume. If the Retail edition connector covers you, we will say so. If it does not, you get the sync matrix for your setup and a fixed price.