Deltek and Cin7 integration

What moves between them

The main flow runs from Cin7 Core into Deltek. When a Purchase in Cin7 Core reaches the INVOICE approach and Authorised status, ml-connector reads the supplier invoice and creates a matching AP invoice in Deltek against the correct vendor firm, GL account, and project. Supplier records flow the same direction so Deltek vendor firms reflect new and updated Cin7 Core suppliers. Reference data, specifically Cin7 Core chart of accounts codes mapped to Deltek GL accounts, is aligned so each invoice line lands on a valid account. The Cin7 Core chart of accounts is read-only over the API, so ml-connector never writes accounts back to Cin7 Core, and Deltek AP invoices are not pushed back as Cin7 Core purchases.

How ml-connector handles it

ml-connector stores both credential sets encrypted. It sends the api-auth-accountid and api-auth-applicationkey headers on every Cin7 Core request, and on the Deltek side it holds the tenant URL, database name, client id and secret, and the API user login, requesting an OAuth2 password-grant token and refreshing it when a call returns 401. Cin7 Core Purchase created and Purchase updated webhooks from the Automation module trigger the work, and because those payloads are unsigned, ml-connector verifies the event by reading the Purchase back from the API before acting, and a scheduled poll backfills anything a webhook missed. Only purchases at the INVOICE approach and Authorised status are turned into Deltek AP invoices, so draft and order-stage records are skipped. Supplier and GL account codes are mapped first so every invoice line references a Deltek firm and account that already exists. Neither API offers an idempotency key, so ml-connector checks Deltek for the supplier invoice number before posting to prevent duplicates, and Cin7 Core 429 responses are retried using the Retry-After header. Note that Deltek AP invoices may pass through an approval workflow in the customer instance, so a posted invoice can land in draft or pending status depending on configuration.

A real-world example

A mid-sized engineering services firm of about 120 staff runs Deltek Vantagepoint for project accounting and uses Cin7 Core to manage equipment, parts inventory, and supplier purchasing across two offices. Before the integration, a clerk exported authorised supplier bills from Cin7 Core each week and re-keyed them into Deltek as AP invoices, matching them to the right project and GL account by hand, which delayed payables and produced coding errors at month-end. With Deltek and Cin7 connected, every authorised Cin7 Core supplier invoice flows into Deltek as an AP invoice already coded to the correct vendor firm, project, and account. Payables are entered the same day, and the manual re-keying step is gone.

What you can do

• •Create Deltek AP invoices from authorised Cin7 Core supplier invoices, coded to the right GL account and project.
• •Keep Deltek vendor firms aligned with Cin7 Core suppliers as they are created and updated.
• •Map Cin7 Core chart of accounts codes to Deltek GL accounts so each invoice line posts to a valid account.
• •Bridge Cin7 Core api-auth header keys and the Deltek OAuth2 tenant token, refreshing the Deltek token automatically.
• •Trigger on Cin7 Core Purchase events, backfill by scheduled poll, and check the invoice number before posting to avoid duplicates.

Questions

Which direction does data move between Deltek and Cin7?

The main flow is Cin7 Core into Deltek. Authorised supplier invoices and supplier records move from Cin7 Core into Deltek as AP invoices and vendor firms. The Cin7 Core chart of accounts is read-only over the API, so ml-connector reads account codes for mapping but never writes accounts back, and Deltek invoices are not pushed back into Cin7 Core.

How does the integration avoid duplicate invoices without an idempotency key?

Neither Deltek nor Cin7 Core exposes an idempotency key header. Before posting an AP invoice, ml-connector queries Deltek for the supplier invoice number and skips the post if a match already exists. Because Cin7 Core webhook payloads are unsigned, it also reads the Purchase back from the API to confirm the event before acting.

Does the integration use the Cin7 Core webhooks or polling?

It uses both. Cin7 Core Purchase created and Purchase updated events from the Automation module trigger the sync as soon as a bill is authorised. Deltek has no usable webhook for this, so a scheduled poll runs on the cadence you set to catch anything the unsigned Cin7 Core events miss and to read Deltek reference data.