Microsoft Dynamics 365 F&O and Cin7 integration

What moves between them

The main flow runs from Cin7 Core into Microsoft Dynamics 365 F&O. New and updated suppliers and products in Cin7 Core are written into Dynamics as VendorsV2 and ReleasedProductsV2 records, and Cin7 Core Purchases are written into Dynamics as PurchaseOrderHeadersV2 with their lines, and as VendorInvoiceHeaders when the Purchase reaches the INVOICE approach. Product and vendor master records also flow from Dynamics back into Cin7 Core so both systems share the same catalog and supplier list. GL account codes and units of measure are aligned in both directions so every purchase line references a valid Dynamics account. The chart of accounts is read-only in Cin7 Core, so ml-connector never writes account definitions back into it. Cin7 Core webhooks and Dynamics Business Events trigger syncs as activity occurs, and a scheduled poll backfills anything a push missed.

How ml-connector handles it

ml-connector stores both credential sets encrypted and attaches them per request: the Cin7 Core account ID and application key headers on one side, and an OAuth 2.0 client credentials bearer token from Microsoft Entra ID on the other, which it refreshes when a Dynamics call returns 401. It accepts the Dynamics environment host as a credential field, since there is no shared base URL, and sets the token scope to that host. Because Dynamics OData entity keys must be fully specified, ml-connector supplies both the natural key and the dataAreaId on every write, and adds cross-company filters for multi-entity customers. It maps Cin7 Core GL account codes and units of measure to Dynamics MainAccounts and financial dimension strings first, so purchase lines and vendor invoices post to accounts that already exist. The Cin7 Core Purchase state machine is respected, so an order is only written as a Dynamics vendor invoice once it reaches the INVOICE approach, and Dynamics vendor invoices are written only before posting since posted invoices are read-only. Dynamics returns HTTP 429 with a Retry-After header when service protection limits trip, and Cin7 Core returns 429 with Retry-After per application key, so ml-connector backs off and retries on both sides. Cin7 Core does not sign its webhooks, so ml-connector relies on a shared secret in the destination URL, and it uses the Dynamics Business Event ControlNumber to deduplicate events. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A wholesale distributor of roughly 80 staff runs Cin7 Core to manage inventory, purchasing, and warehouse operations across two locations, and runs Microsoft Dynamics 365 F&O as the corporate finance and procurement system. Before the integration, the warehouse team raised purchases in Cin7 Core while finance re-keyed the same purchase orders and supplier invoices into Dynamics, which meant duplicate data entry, mismatched item codes, and supplier invoices that lagged the goods receipt by days. With the two systems connected, each Cin7 Core purchase flows into Dynamics as a purchase order and, once invoiced, as a vendor invoice against the mapped GL accounts, and product and supplier masters stay aligned automatically. Finance closes the procure-to-pay loop without re-entry, and the warehouse and the ledger reference the same items and vendors.

What you can do

• •Write Cin7 Core purchases into Microsoft Dynamics 365 F&O as purchase orders, and as vendor invoices once they reach the INVOICE approach.
• •Keep supplier and product masters aligned between Cin7 Core and Dynamics in both directions.
• •Map Cin7 Core GL account codes and units of measure to Dynamics main accounts and financial dimensions so lines post to valid accounts.
• •Bridge Cin7 Core account ID and application key headers with the OAuth 2.0 client credentials token Dynamics requires through Microsoft Entra ID.
• •Trigger syncs from Cin7 Core webhooks and Dynamics Business Events, with scheduled polling, retries, and a full audit trail on every record.

Questions

Which direction does data move between Microsoft Dynamics 365 F&O and Cin7?

The main flow runs from Cin7 Core into Microsoft Dynamics 365 F&O. Suppliers, products, and purchases move into Dynamics as vendors, released products, purchase orders, and vendor invoices, while product and vendor masters are aligned in both directions. The Cin7 Core chart of accounts is read-only through the API, so ml-connector never writes account definitions back into it.

How does the integration bridge the two different authentication schemes?

Cin7 Core uses two static header credentials, an account ID and an application key, on every call, while Microsoft Dynamics 365 F&O uses an OAuth 2.0 client credentials bearer token issued by Microsoft Entra ID and scoped to the tenant environment host. ml-connector stores both credential sets encrypted, attaches the right ones per request, and refreshes the Dynamics token when a call returns 401. It also accepts the Dynamics environment host as a credential field since there is no shared base URL.

How are duplicate records and supplier invoices kept from being created twice?

Neither system exposes an idempotency key, so ml-connector deduplicates using natural keys: the Cin7 Core Purchase Reference field and the Dynamics InvoiceNumber and vendor account. It also reads the ControlNumber on Dynamics Business Events to detect repeated event deliveries. A Cin7 Core purchase is only written as a Dynamics vendor invoice once it reaches the INVOICE approach, and Dynamics vendor invoices are written before posting, since posted invoices are read-only through OData.