Acumatica and Cin7 integration

What moves between them

Suppliers and procurement documents move between Acumatica and Cin7 Core. Supplier or vendor master records are aligned in both directions so each side holds the same supplier list keyed on a shared code. Purchases flow from Cin7 Core into Acumatica, where a Cin7 Core Purchase with Approach ORDER becomes an Acumatica purchase order and one with Approach INVOICE becomes an Acumatica AP bill against the matching vendor and GL accounts. GL account codes are read from Cin7 Core, which exposes them read-only, and mapped to Acumatica accounts so each line posts correctly. Cadence is set per flow, from frequent intraday polling to a nightly run, with a high-water mark stored after each sync.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Acumatica side it accepts the full tenant URL and the endpoint version per customer, requests an OAuth token, and refreshes it when a call returns 401, while unwrapping Acumatica field values that arrive as a value object. On the Cin7 Core side it sends the api-auth-accountid and api-auth-applicationkey headers on every request and pages with the page and limit parameters. Because the Cin7 Core Purchase endpoint multiplexes the whole procure-to-pay cycle, the connector reads the Approach and Status fields to decide whether a record maps to an Acumatica purchase order or an AP bill, and on write it creates the record as Draft then issues the separate Authorise call. Supplier and GL account codes are mapped first so every line lands on a valid Acumatica vendor and account, and the chart of accounts is treated as read-only on the Cin7 Core side. Both APIs return HTTP 429 when rate limited, Acumatica once the request count crosses the licensed threshold and Cin7 Core with a Retry-After header, so ml-connector backs off with jitter and retries. Where Cin7 Core Automation webhooks are enabled the connector can receive them, but since those payloads are unsigned it relies on a shared-secret token and falls back to polling as a catch-up. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized wholesale distributor runs Acumatica for its general ledger and AP, and runs Cin7 Core for inventory, purchasing, and supplier management across a couple of warehouses. Before the integration, a buyer raised purchase orders and recorded supplier invoices in Cin7 Core, then a finance clerk re-keyed each bill into Acumatica every few days, picking the right vendor and GL accounts by hand and reconciling the two supplier lists at month-end. With Acumatica and Cin7 connected, each authorised Cin7 Core purchase flows into Acumatica as a purchase order or AP bill on the matching vendor and accounts, and the supplier records stay aligned. The clerk stops re-entering bills and month-end close starts with the AP side already matching procurement.

What you can do

• •Sync supplier records between Acumatica and Cin7 so both systems hold the same vendor list on a shared code.
• •Turn Cin7 Core purchases into Acumatica purchase orders or AP bills based on the Approach and Status fields.
• •Map Cin7 Core supplier and GL account codes to Acumatica vendors and accounts so every line posts correctly.
• •Bridge Acumatica OAuth 2.0 and the Cin7 Core api-auth-accountid and api-auth-applicationkey header auth.
• •Poll on a schedule with retries, Retry-After backoff, and a full audit trail on every record.

Questions

Which direction does data move between Acumatica and Cin7?

Supplier records are aligned in both directions so each system holds the same vendor list. Purchase documents flow from Cin7 Core into Acumatica, where a Cin7 Core purchase becomes either an Acumatica purchase order or an AP bill depending on its Approach field. GL account codes are read from Cin7 Core, which exposes the chart of accounts read-only, and mapped onto Acumatica accounts.

How does the integration handle the Cin7 Core Purchase lifecycle?

A Cin7 Core Purchase is not just a PO. The same endpoint tracks the order, the goods receipt, and the supplier invoice through its Approach and Status fields. ml-connector reads those fields to decide what each record maps to in Acumatica, and on write it creates the record as Draft then makes the separate Authorise call that Cin7 Core requires.

How are the two different authentication schemes connected?

Acumatica uses OAuth 2.0 through its built-in identity server with a tenant-specific URL and a version-matched endpoint, while Cin7 Core uses two static API key headers, api-auth-accountid and api-auth-applicationkey. ml-connector stores both credential sets encrypted, presents the right one to each system on every call, and refreshes the Acumatica token when a request returns 401. Cin7 Core keys do not expire, so they are used as provisioned.