Acumatica and ShipStation integration

What moves between them

The primary flow runs from Acumatica into ShipStation. As sales orders reach a fulfillable state in Acumatica, ml-connector posts them into ShipStation as orders, carrying the customer, ship-to address, and line items keyed by SKU. Customers and stock items move the same direction so each ShipStation order line resolves to a known product. The return flow runs from ShipStation into Acumatica: once a shipment is created and a label prints, the tracking number, carrier, and ship date post back so the Acumatica order is marked shipped. Financial postings such as invoices stay in Acumatica, since ShipStation has no accounting objects to write to.

How ml-connector handles it

ml-connector stores both credential sets encrypted, sends the ShipStation Base64 Basic auth header on V1 calls and the API-Key header on V2 label calls, and accepts the full Acumatica instance URL plus the exact endpoint version per customer, since a version mismatch returns 404. Outbound orders post to ShipStation createorder using the Acumatica order number as orderKey, so a re-send updates the existing order rather than creating a duplicate, and every Acumatica field value is sent inside the required value object so reads parse cleanly. Inbound shipments are caught two ways: the SHIP_NOTIFY webhook delivers only a resource_url, which ml-connector follows with an authenticated GET to fetch the shipment, and a scheduled poll on modifyDate backfills anything a webhook missed, since ShipStation has no order-update event. ShipStation V1 timestamps are PST or PDT, so they are converted before being written to Acumatica. Both sides return HTTP 429 under load, ShipStation V1 at roughly 40 requests per minute, so ml-connector backs off with jitter, and once an order is shipped or cancelled in ShipStation it is immutable, so late edits are reconciled rather than overwritten.

A real-world example

A mid-sized e-commerce brand with around 150 employees sells finished goods through several online channels and runs Acumatica Cloud ERP for inventory, pricing, and order management, with ShipStation as the warehouse shipping tool. Before the integration, a coordinator exported each batch of Acumatica sales orders, re-entered them into ShipStation to print labels, then typed tracking numbers back into Acumatica by hand so customers could be notified. With Acumatica and ShipStation connected, sales orders flow into ShipStation automatically with the right customer and SKUs, labels print against live data, and tracking numbers post back to the matching Acumatica order. The double entry is gone, and orders move from sale to shipped without a coordinator retyping them.

What you can do

• •Push Acumatica sales orders into ShipStation as orders to fulfill, with customer, address, and SKU lines intact.
• •Keep ShipStation customers and products aligned with Acumatica so every order line maps to a known item.
• •Read ShipStation shipments back into Acumatica to mark orders shipped with tracking number and carrier.
• •Authenticate ShipStation with V1 Basic auth and V2 API-Key, and Acumatica with its version-locked tenant login.
• •Catch shipments by SHIP_NOTIFY webhook plus a modifyDate poll, with retries, error replay, and a full audit trail.

Questions

Which direction does data move between Acumatica and ShipStation?

Both directions, with a clear split. Sales orders, customers, and stock items move from Acumatica into ShipStation so the warehouse can ship, and shipment data moves back from ShipStation into Acumatica to mark orders shipped with tracking. Financial records such as invoices stay in Acumatica, since ShipStation has no GL accounts or accounting objects to receive them.

How does the integration catch order edits when ShipStation has no order-update webhook?

ShipStation fires ORDER_NOTIFY and SHIP_NOTIFY for new orders and shipments, but it has no event for order edits. ml-connector follows each webhook's resource_url with an authenticated GET to fetch the real data, then runs a scheduled poll on modifyDate to catch updates the webhooks miss. ShipStation V1 timestamps are PST or PDT, so they are converted before posting to Acumatica.

How does the connector handle Acumatica's version-locked URL and prevent duplicate orders in ShipStation?

ml-connector accepts the full Acumatica instance URL and the exact endpoint version per customer, since a version mismatch returns a 404, and it wraps every field value in the value object Acumatica requires. When pushing to ShipStation it uses the Acumatica order number as the orderKey, which ShipStation treats as a natural key, so re-sending the same order updates it rather than creating a duplicate.