QAD and Adobe Commerce integration

What moves between them

The main flow runs from Adobe Commerce into QAD. ml-connector reads sales orders, the invoices captured against them, and credit memos from Adobe Commerce and posts them into QAD as customer sales and receivables, mapped to the matching QAD items, customers, and accounts. Customer and company records flow the same direction so the QAD customer master reflects storefront buyers and B2B accounts. Product and SKU references are aligned so each order line resolves to a real QAD item number. GL postings stay in QAD, since Adobe Commerce has no GL resource, so ml-connector never writes ledger entries back to the store.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Adobe Commerce side it signs each PaaS request with the OAuth 1.0a consumer and access tokens, or requests and refreshes an IMS OAuth 2.0 bearer token for the Cloud Service before it expires, and it scopes every call to the right store view by URL path or header. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base URL, and validates entity paths against that instance. Because QAD cloud is pull-only, it polls Adobe Commerce orders, invoices, and credit memos on a schedule rather than waiting for a push, paging through results with searchCriteria and the total_count field. Items and customers are mapped first, so every order line references a QAD item and a customer that already exist. Adobe Commerce has no idempotency key header, so ml-connector dedupes on the increment_id and a BullMQ jobId before it posts to QAD, which avoids double-booking a re-read order. Where Adobe Commerce webhooks are enabled, ml-connector can take a push as a trigger, but it keeps a synchronous endpoint fast so storefront operations do not stall. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized industrial parts maker runs QAD Adaptive ERP for production, inventory, and finance, and sells spares to dealers through an Adobe Commerce B2B storefront. Before the integration, a clerk printed each web order and keyed it into QAD by hand, which meant orders sat for hours, SKUs were sometimes typed wrong, and the receivables in the ledger never matched the storefront totals. With QAD and Adobe Commerce connected, each order and its captured invoice flow into QAD within the polling window, allocated to the correct customer and item, and refunds post as credit notes. Orders ship sooner, the keying errors are gone, and the sales accounts reconcile without a month-end scramble.

What you can do

• •Post Adobe Commerce sales orders and captured invoices into QAD as customer sales and receivables.
• •Map Adobe Commerce SKUs to QAD item numbers so every order line lands on a real part.
• •Keep the QAD customer master aligned with Adobe Commerce storefront buyers and B2B company accounts.
• •Authenticate Adobe Commerce with OAuth 1.0a or IMS OAuth 2.0, and QAD with its tenant-specific token.
• •Poll on a schedule with increment_id and jobId dedup, retries, and a full audit trail on every record.

Questions

Which direction does data move between QAD and Adobe Commerce?

The main flow is Adobe Commerce into QAD. Sales orders, invoices, credit memos, and customer records move from Adobe Commerce into QAD, while item and SKU references are aligned so order lines resolve to real parts. Adobe Commerce has no GL account resource, so the general ledger stays in QAD and ml-connector never writes ledger entries back to the store.

How does the integration handle Adobe Commerce PaaS versus the Cloud Service?

ml-connector supports both deployment models. For PaaS it signs each request with OAuth 1.0a integration credentials, and for the Cloud Service it requests and refreshes an IMS OAuth 2.0 bearer token before its roughly 24-hour expiry. It also scopes every call to the correct store view, by URL path on PaaS or by header on the Cloud Service.

Does Adobe Commerce push orders, or does ml-connector poll for them?

Both are supported, but polling is the default because QAD cloud is pull-only. ml-connector reads orders, invoices, and credit memos on a schedule, paging with searchCriteria and total_count. Where Adobe Commerce webhooks are enabled it can take a push as a trigger, while keeping the synchronous endpoint fast so storefront operations are not held up.