Which direction does data move between QAD and ShipStation?

The main flow is ShipStation into QAD. Shipped orders, shipments, and customer data move from ShipStation into QAD, while product and catalog data flows from QAD out to ShipStation. ShipStation has no GL accounts or AP invoices, so ml-connector moves no financial entries and QAD stays the accounting system of record.

How does the integration handle ShipStation webhooks and order edits?

ml-connector subscribes to the ORDER_NOTIFY and SHIP_NOTIFY webhooks, but those payloads contain only a resource_url, so it makes a second authenticated call to fetch the real order or shipment. Because ShipStation sends no webhook when an order is edited, ml-connector also polls GET /orders by modifyDate on a schedule to catch those changes.

Does the split between ShipStation V1 and V2 APIs cause problems?

No. ml-connector uses V1 with HTTP Basic auth for order, customer, and product management and V2 with the API-Key header for label and inventory operations, since V2 has no general orders list endpoint. It stores both credential sets encrypted and presents the correct one per call, and it bridges them with the QAD tenant-specific login.

QADShipStation

QAD and ShipStation integration

QAD runs manufacturing and finance. ShipStation runs e-commerce order and shipping operations across sales channels. Connecting the two moves order and shipment activity into QAD without re-keying, and keeps the product catalog ShipStation ships against in step with QAD item masters. Shipped orders and tracking details flow into QAD so sales, fulfillment, and inventory stay aligned with what actually left the warehouse. ml-connector handles the split between ShipStation V1 and V2 APIs and moves the data on a schedule you control.

How QAD works

QAD Adaptive ERP exposes customers, items, suppliers, purchase orders, supplier invoices, GL accounts, cost centers, and goods receipts through REST business document APIs, documented in Swagger inside each customer instance. The cloud product authenticates with a JWT session or OAuth2 bearer token against a tenant-specific URL, so there is no shared hostname and no public developer portal. Older on-premise sites run QAD Enterprise Edition with the QXtend SOAP framework instead. QAD cloud has no webhook system for connectors, so records are read by polling on a schedule.

How ShipStation works

ShipStation runs two REST API versions. V1 owns order, customer, product, and warehouse management and uses HTTP Basic auth with a Base64-encoded apiKey and apiSecret. V2 owns label, manifest, and inventory purchase order operations and uses an API-Key header with no Bearer prefix; it has no general orders list endpoint by design. ShipStation pushes outbound webhooks for new orders and shipments, but the payload is only a resource_url pointer that the handler must fetch with a second authenticated call, and there is no webhook for order edits. V1 datetimes are PST or PDT, not UTC.

What moves between them

The main flow runs from ShipStation into QAD. ml-connector reads shipped and updated orders and their shipment records, including tracking numbers, carriers, and line items, and posts them into QAD as sales orders and fulfillment data mapped to the matching QAD customers and items. Product and catalog data flows the other direction so ShipStation carries QAD SKUs, costs, and customs values. Customers are read from ShipStation and matched to QAD records, since ShipStation creates customers implicitly from order data rather than through a direct write. ShipStation has no GL accounts or AP invoices, so no financial entries move; QAD remains the accounting system of record.

How ml-connector handles it

ml-connector stores both credential sets encrypted and presents ShipStation V1 Basic auth and the V2 API-Key header on the matching calls, while accepting the full QAD tenant URL per customer since QAD publishes no shared base address. It subscribes to the ShipStation ORDER_NOTIFY and SHIP_NOTIFY webhooks, and because those payloads carry only a resource_url it makes the follow-up authenticated GET to pull the real order or shipment before mapping it into QAD. Since ShipStation fires no webhook on order edits, it also polls GET /orders by modifyDate on a schedule to catch changes the push misses, and it converts the PST or PDT timestamps to UTC on ingest. The orderKey field is used as the stable external reference so a re-posted order updates the existing QAD record instead of duplicating. ShipStation rate limits return HTTP 429 at 40 requests per minute on V1 and 200 on V2, so ml-connector backs off and retries within those windows, and shipped or cancelled orders are treated as immutable. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A direct-to-consumer goods maker with around 150 staff runs QAD Adaptive ERP for production, procurement, and finance, and uses ShipStation to consolidate orders from its Shopify and Amazon channels and print labels across several carriers. Before the integration, a clerk exported shipped-order reports from ShipStation each day and keyed sales and tracking details into QAD by hand, and the catalog drifted because new QAD items were added to ShipStation manually. With QAD and ShipStation connected, shipped orders and tracking flow into QAD automatically against the right customers and items, and QAD item changes propagate to ShipStation, so inventory and fulfillment records reflect what actually shipped without daily re-keying.

What you can do

Post ShipStation shipped orders and shipment records into QAD as sales and fulfillment data against matching customers and items.
Push QAD item masters to ShipStation so products carry the correct SKU, cost, and customs values.
Subscribe to ShipStation order and shipment webhooks and fetch each resource_url before mapping into QAD.
Poll ShipStation by modifyDate to capture the order edits that ShipStation sends no webhook for.
Bridge ShipStation V1 Basic auth and V2 API keys with QAD tenant login, with retries and a full audit trail on every record.

Questions

Which direction does data move between QAD and ShipStation?: The main flow is ShipStation into QAD. Shipped orders, shipments, and customer data move from ShipStation into QAD, while product and catalog data flows from QAD out to ShipStation. ShipStation has no GL accounts or AP invoices, so ml-connector moves no financial entries and QAD stays the accounting system of record.
How does the integration handle ShipStation webhooks and order edits?: ml-connector subscribes to the ORDER_NOTIFY and SHIP_NOTIFY webhooks, but those payloads contain only a resource_url, so it makes a second authenticated call to fetch the real order or shipment. Because ShipStation sends no webhook when an order is edited, ml-connector also polls GET /orders by modifyDate on a schedule to catch those changes.
Does the split between ShipStation V1 and V2 APIs cause problems?: No. ml-connector uses V1 with HTTP Basic auth for order, customer, and product management and V2 with the API-Key header for label and inventory operations, since V2 has no general orders list endpoint. It stores both credential sets encrypted and presents the correct one per call, and it bridges them with the QAD tenant-specific login.

Connect QAD and ShipStation

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started