Acumatica and WooCommerce integration

What moves between them

The primary flow runs from WooCommerce into Acumatica. As orders are placed and paid, ml-connector reads the order, its line items, and any refunds and creates the matching AR sales invoice in Acumatica, creating or updating the customer first so each document links to a valid account. The reverse flow runs from Acumatica to WooCommerce: stock item price and inventory level changes update the corresponding WooCommerce catalog products by SKU. Order capture is event-driven on WooCommerce webhooks with a scheduled poll as a catch-up, and catalog pushes run on the schedule you set. Because WooCommerce has no GL resource, ml-connector never writes ledger entries back to the store.

How ml-connector handles it

ml-connector stores both credential sets encrypted, sends the WooCommerce Consumer Key and Secret as HTTP Basic credentials on every store call, and runs the Acumatica OAuth flow against the customer's instance, refreshing the bearer token when a call returns 401. It pins the exact Acumatica endpoint version per customer so the version-locked URL resolves, and wraps every field value as {"value": ...} the way the Contract-Based REST API requires. WooCommerce order webhooks are verified against the X-WC-Webhook-Signature HMAC before processing, and SKUs are matched to Acumatica InventoryID so catalog and order lines land on the right items. Neither API has a native idempotency key, so ml-connector dedupes on the WooCommerce order id and a BullMQ jobId before posting, which avoids double-booking a re-read order. WooCommerce disables a webhook after five consecutive failures, so a health check re-registers it, and a scheduled poll on LastModifiedDateTime backfills anything a missed push dropped. Acumatica returns HTTP 429 once the per-minute request count crosses its licensed threshold, so ml-connector backs off with jitter, and on shared hosts that strip the Authorization header it falls back to the query-string credential form. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized consumer goods seller with roughly 60 staff runs an online store on WooCommerce and uses Acumatica Cloud ERP for inventory, AR, and finance. Before the integration, a clerk exported each day's web orders from WooCommerce and re-typed them into Acumatica as invoices, mistyped SKUs and customer details caused billing and picking errors, and the storefront showed stock the warehouse had already sold. With Acumatica and WooCommerce connected, paid orders post into Acumatica within minutes as AR sales invoices against matched customers, refunds post as credit notes, and Acumatica inventory levels push back to the catalog so the store stops overselling. The manual entry step is gone and the two systems stay reconciled through the day.

What you can do

• •Create Acumatica AR sales invoices from paid WooCommerce orders, with the customer matched or created first.
• •Post WooCommerce refunds against the right Acumatica documents as credit notes.
• •Push Acumatica stock item price and inventory updates to WooCommerce catalog products by SKU.
• •Bridge the WooCommerce Consumer Key and Acumatica OAuth, pinning the exact version-locked endpoint URL.
• •Capture orders on WooCommerce HMAC-signed webhooks with a scheduled LastModifiedDateTime poll as catch-up, plus retries and a full audit trail.

Questions

Which direction does data move between Acumatica and WooCommerce?

Orders, refunds, and shoppers move from WooCommerce into Acumatica as AR sales invoices and customers. Product price and inventory move the other way, from Acumatica out to the WooCommerce catalog. WooCommerce has no GL account resource, so the general ledger stays in Acumatica and ml-connector never writes ledger entries back to the store.

How does the integration deal with Acumatica's version-locked endpoint and field wrapping?

ml-connector accepts the customer's instance URL and exact endpoint version, such as 24.200.001, and pins it on every call so the version-locked path resolves instead of returning 404. It also wraps each field value as a {"value": ...} object, which the Contract-Based REST API requires; flat key-value pairs would be rejected with a 400. Both are handled automatically from the stored configuration.

Does the integration rely on WooCommerce webhooks, and what if one is missed?

Yes. WooCommerce pushes HMAC-SHA256 signed webhooks for order, customer, and product events, which ml-connector verifies against the X-WC-Webhook-Signature header before acting on them. Because WooCommerce disables a webhook after five consecutive delivery failures, a health check re-registers it and a scheduled poll on LastModifiedDateTime backfills anything a missed push dropped, so no paid order is lost.