QAD and Amazon Seller Central integration

What moves between them

The main flow runs from Amazon Seller Central into QAD. ml-connector reads buyer orders and posts them into QAD as customer sales orders with the right item lines, then reads the settlement report, the authoritative record of what Amazon actually paid out, and posts the disbursements and fees into QAD as receivables and GL entries. FBA and merchant inventory summaries flow the same direction to keep QAD item stock aligned with what Amazon holds. In the other direction, QAD catalog and item data can be pushed to Amazon listings so product details stay current. Orders and inventory are read frequently; settlement data is read after Amazon closes each statement.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Amazon side it exchanges the seller refresh token for an access token, caches it, and refreshes before the one-hour expiry rather than per call, attaching the access token and marketplace ID to every request. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base address, and validates entity paths against that instance. Because both systems are pull-based for finance, it polls on a schedule: orders and inventory often, settlement reports after each statement closes. SP-API uses cursor pagination, so the connector follows the NextToken until it is absent and never assumes one page holds every order. Marketplace ID and region are required on each call, and a seller in more than one region is handled with separate calls per region. SKUs map to QAD item numbers so each order line references a real item, and buyer PII is only requested with a Restricted Data Token when an address is actually needed. SP-API rate limits return HTTP 429 from a token bucket, so the connector backs off with jitter and retries, and every record carries a full audit trail and can be replayed if a downstream post fails.

A real-world example

A consumer goods manufacturer of about 200 staff makes its own products and sells them direct on Amazon as well as through wholesale channels, running QAD Adaptive ERP for production, inventory, and finance. Before the integration, an operations clerk downloaded the Amazon settlement report every two weeks and keyed the order totals, fees, and payouts into QAD by hand, while warehouse stock in QAD drifted out of step with what Amazon held in FBA. With QAD and Amazon Seller Central connected, orders post into QAD as they arrive, each settlement flows in as receivables and fee entries against the right accounts, and inventory stays aligned. The clerk stops re-keying, and finance reconciles Amazon payouts against the ledger without chasing a spreadsheet.

What you can do

• •Post Amazon Seller Central buyer orders into QAD as customer sales orders with matching item lines.
• •Read Amazon settlement reports and record disbursements and fees in QAD as receivables and GL entries.
• •Keep QAD item stock aligned with Amazon FBA and merchant-fulfilled inventory levels.
• •Push QAD catalog and item data out to Amazon listings to keep product details current.
• •Bridge Amazon SP-API OAuth2 token refresh and QAD tenant login, with polling, retries, and a full audit trail.

Questions

Which direction does data move between QAD and Amazon Seller Central?

The main flow is Amazon Seller Central into QAD. Orders, settlement payouts, and inventory levels move from Amazon into QAD, while catalog and item data can be pushed outward to Amazon listings. This keeps sales orders, receivables, and stock in the ERP without manual entry.

Does Amazon Seller Central support webhooks, or does the connection poll?

Amazon does not deliver plain HTTP webhooks. Push events are routed only through AWS EventBridge or SQS, so a REST connector polls instead. ml-connector polls the Orders, Finances, and Reports APIs on a schedule, reading orders and inventory frequently and settlement reports after each statement closes.

How does the integration handle Amazon authentication and rate limits?

ml-connector exchanges the seller refresh token from Login with Amazon for one-hour access tokens, caches them, and refreshes before expiry, adding the marketplace ID to each call. SP-API enforces a token-bucket rate limit that returns HTTP 429, so the connector backs off with jitter and retries the request rather than failing the sync.