Which direction does data move between QAD and Zendesk?

Customers and contacts flow from QAD into Zendesk, becoming organizations and users with the QAD id stored on external_id. Ticket activity flows the other way, from Zendesk to ml-connector, so support history can be linked to the matching QAD account. There is no financial data in either direction because Zendesk holds no invoices, purchase orders, or GL records.

Can Zendesk hold QAD invoices or order data?

No. Zendesk is a support platform and has no native invoices, purchase orders, payments, or GL accounts. This integration keeps account and contact records aligned and links tickets back to the QAD customer using external_id, so agents have context, but the order and billing data stays in QAD as the system of record.

How does the integration get ticket updates from Zendesk?

Zendesk pushes ticket created, updated, and solved events through signed webhooks, and ml-connector verifies the HMAC-SHA256 signature and timestamp before accepting each delivery. Ticket webhooks must be wired to a Zendesk trigger or automation to fire, which is set up at onboarding. The connector also reads the Incremental Export API as a backstop so no ticket changes are missed.

QADZendesk

QAD and Zendesk integration

QAD Adaptive ERP runs manufacturing, order management, and finance. Zendesk runs customer support: tickets, users, and organizations. Connecting the two means support agents in Zendesk see the same customers and contacts that QAD treats as the system of record, and ticket activity can be tied back to the QAD account it belongs to. Zendesk has no invoices, purchase orders, or GL accounts, so this integration is about keeping account and contact records aligned and giving support a link to the order and billing data in QAD. Records sync on a schedule you control, with ticket events delivered by webhook.

How QAD works

QAD Adaptive ERP exposes suppliers, customers, items, purchase orders, supplier invoices, GL accounts, cost centers, goods receipts, and AP payments 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 sandbox. Older on-premise sites run QAD Enterprise Edition with the QXtend SOAP framework instead. QAD cloud has no native webhook system for third-party connectors, so customer and order records are read by polling on a schedule.

How Zendesk works

Zendesk exposes its Support data through a REST API over HTTPS, scoped to each customer's subdomain at https://{subdomain}.zendesk.com/api/v2/. The core entities are tickets, users (customers and agents), organizations (the account-level record), and groups. The recommended connector auth is the OAuth 2.0 authorization code flow, which yields a bearer access token scoped to one subdomain with read and write scopes. Zendesk has no native finance objects: no invoices, purchase orders, payments, or GL accounts. It does push events through signed webhooks, and it offers an Incremental Export API and cursor pagination for delta reads.

What moves between them

Account and contact data flows from QAD into Zendesk. ml-connector reads QAD customers and writes them into Zendesk organizations, putting the QAD customer id into the organization external_id so the account is findable from either side, and it maps QAD contacts to Zendesk users with the same external id link. Ticket activity flows the other direction: Zendesk delivers ticket created, updated, and solved events by webhook, and ml-connector reads them and the incremental ticket export so support history can be associated with the matching QAD customer. There is no financial data in this flow, because Zendesk holds no invoices or GL records. The cadence is webhook-driven for tickets plus a scheduled poll for organizations and users, typically every few minutes.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Zendesk side it runs the OAuth 2.0 authorization code flow against the customer's subdomain, stores the resulting bearer token, and re-runs the authorize step if a call is rejected, since Zendesk documents no fixed token expiry. 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. QAD customers map to Zendesk organizations and QAD contacts to Zendesk users, with the QAD id written to external_id as the join key. Because QAD cloud is pull-only, organizations and users are synced by polling, while Zendesk ticket events arrive by webhook; ml-connector verifies the X-Zendesk-Webhook-Signature HMAC-SHA256 header and checks the timestamp for freshness before accepting a delivery, and returns 401 on a bad signature. Ticket webhooks require a Zendesk trigger or automation wired to fire them, so that is configured at onboarding. Zendesk user email is writable only on create, so updates add a secondary address rather than replacing the primary, and the connector accounts for that. Zendesk rate limits return HTTP 429 with a Retry-After header, so the connector backs off and retries, and it uses cursor pagination rather than offset to stay under the 10,000-record offset cap. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized industrial equipment maker with around 500 employees runs QAD Adaptive ERP for order management and finance, and its support desk runs on Zendesk. Before the integration, support agents could not tell which Zendesk requester matched which QAD customer, so they kept a side spreadsheet of account names and re-typed company records into Zendesk by hand whenever a new customer was onboarded in QAD. With QAD and Zendesk connected, each QAD customer becomes a Zendesk organization with the QAD id stored on external_id, contacts become users, and incoming tickets are linked to the right account automatically. Agents open a ticket and see the matching QAD customer, and the manual re-keying of company and contact records is gone.

What you can do

Sync QAD customers into Zendesk organizations and QAD contacts into Zendesk users, keyed by external_id.
Write the QAD record id into Zendesk external_id so each support account links back to QAD.
Receive Zendesk ticket created, updated, and solved events by signed webhook and tie them to the matching QAD customer.
Authenticate Zendesk with the OAuth 2.0 authorization code flow and QAD with its tenant-specific token.
Verify webhook signatures, use cursor pagination and incremental export, back off on 429, and keep a full audit trail on every record.

Questions

Which direction does data move between QAD and Zendesk?: Customers and contacts flow from QAD into Zendesk, becoming organizations and users with the QAD id stored on external_id. Ticket activity flows the other way, from Zendesk to ml-connector, so support history can be linked to the matching QAD account. There is no financial data in either direction because Zendesk holds no invoices, purchase orders, or GL records.
Can Zendesk hold QAD invoices or order data?: No. Zendesk is a support platform and has no native invoices, purchase orders, payments, or GL accounts. This integration keeps account and contact records aligned and links tickets back to the QAD customer using external_id, so agents have context, but the order and billing data stays in QAD as the system of record.
How does the integration get ticket updates from Zendesk?: Zendesk pushes ticket created, updated, and solved events through signed webhooks, and ml-connector verifies the HMAC-SHA256 signature and timestamp before accepting each delivery. Ticket webhooks must be wired to a Zendesk trigger or automation to fire, which is set up at onboarding. The connector also reads the Incremental Export API as a backstop so no ticket changes are missed.

Connect QAD and Zendesk

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

Get started