Acumatica and Zendesk integration

What moves between them

The main flow runs from Acumatica into Zendesk. ml-connector reads Acumatica Customer and Vendor records and writes them into Zendesk as organizations, storing the Acumatica code in the organization external_id so each account is matched on later runs rather than duplicated. Acumatica contacts and employees flow the same direction as Zendesk users, linked to their organization, with the email written on create. Ticket activity moves the other way: solved and updated tickets are read from Zendesk and attached to the related Acumatica account for support context. Invoices, bills, purchase orders, and GL postings stay in Acumatica, since Zendesk has no place to hold them, so ml-connector never writes finance data into Zendesk.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Acumatica side it runs the OAuth 2.0 flow against the instance identity server, accepts the full instance URL and the exact endpoint version per customer since a version mismatch returns a 404, and wraps every field value in the required value object. On the Zendesk side it runs the authorization code flow against the customer's subdomain and sends the bearer token, refreshing by redirecting back to the authorize endpoint when a token is rejected. Acumatica Customers and Vendors map to Zendesk organizations keyed by external_id, and contacts map to users; an organization is looked up by external_id before each write so updates land on the existing record. Because Acumatica push notifications are not guaranteed and arrive with only a shared-secret header rather than a signed body, the connector polls Acumatica on LastModifiedDateTime and stores the high-water mark, while inbound Zendesk webhooks are verified by HMAC-SHA256 before use. Real edge cases are handled directly: the Zendesk user email is writable on create only, so an update adds a secondary email rather than replacing the primary; offset pagination past 10,000 records fails, so cursor pagination or the Incremental Export API is used for large pulls; Acumatica has no idempotency key, so the connector checks for an existing record by natural key and dedupes on a BullMQ jobId; and on a Zendesk 429 it honors the Retry-After header. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized distribution company with roughly 250 employees runs Acumatica Cloud ERP for its customer and vendor masters, orders, and finance, and runs Zendesk for its support desk. Before the integration, support agents worked from a Zendesk organization list that drifted out of date: new customers onboarded in Acumatica were missing in Zendesk, renamed accounts did not match, and agents wasted time confirming who a caller actually was. With Acumatica and Zendesk connected, each new or changed Acumatica Customer and Vendor creates or updates the matching Zendesk organization within the polling window, keyed by external_id so nothing is duplicated, and contacts arrive as Zendesk users. Agents open a ticket already tied to the correct account, and ticket history flows back to Acumatica so account managers can see open support issues without leaving the ERP.

What you can do

• •Create and update Zendesk organizations from Acumatica Customer and Vendor records, matched on external_id.
• •Sync Acumatica contacts and employees into Zendesk as users linked to their organization.
• •Read solved and updated Zendesk tickets back into Acumatica as support context on the related account.
• •Bridge Acumatica instance-URL OAuth 2.0 and Zendesk subdomain OAuth, with version-locked endpoint handling.
• •Poll Acumatica on LastModifiedDateTime and verify Zendesk HMAC-SHA256 webhooks, with retries and a full audit trail.

Questions

Which direction does data move between Acumatica and Zendesk?

The main flow is Acumatica into Zendesk. Customer and Vendor records become Zendesk organizations and contacts become users, each keyed by external_id so accounts are matched rather than duplicated. Ticket activity is read the other way, from Zendesk back into Acumatica for support context, and finance data stays in Acumatica because Zendesk has no invoice, purchase order, or GL objects.

Can Acumatica invoices or purchase orders be sent into Zendesk?

No. Zendesk is a customer support platform and has no native invoice, bill, purchase order, payment, or GL account objects. What it does hold is tickets, users, and organizations, so ml-connector syncs the Acumatica account master and contacts into Zendesk and leaves all finance documents in Acumatica, using the Zendesk external_id field as the link back to the ERP record.

How does the integration keep the two systems in sync without reliable push from Acumatica?

Acumatica push notifications are optional, not guaranteed, and carry only a shared-secret header rather than a signed body, so ml-connector polls Acumatica on the LastModifiedDateTime field and keeps a high-water mark between runs. Inbound Zendesk webhooks are verified by their HMAC-SHA256 signature before they are processed. For large reads it uses cursor pagination or the Zendesk Incremental Export API, since offset pagination fails past 10,000 records.