Microsoft Dynamics 365 F&O and Tradeshift integration

What moves between them

Two flows run between the systems. Supplier invoices move from Tradeshift into Microsoft Dynamics 365 F&O: ml-connector pulls UBL invoice documents from the Tradeshift inbox and creates the vendor invoice header and lines in D365 before posting, mapped to the matching vendor account and procurement category. Purchase orders move the other way, from D365 confirmed orders out to Tradeshift as UBL order documents so suppliers receive them on the network. Credit notes follow the invoice path inbound. Trading partner identities are aligned so each Tradeshift tenant UUID resolves to a D365 vendor account. The cadence is a scheduled poll of the changedAfter document list, since Tradeshift offers no plain webhook.

How ml-connector handles it

ml-connector stores both credential sets encrypted and signs every Tradeshift request with OAuth 1.0a HMAC-SHA1 while attaching the X-Tradeshift-TenantId header, and on the D365 side it requests an Entra ID client-credentials token against the customer environment host and refreshes it when a call returns 401. Because Tradeshift has no plain webhook, it polls documents/v2 filtered by mailbox, type, and changedAfter on the schedule you set, then parses each UBL XML body and maps cbc:ID, the supplier party, line items, and totals into the D365 VendorInvoiceHeaders and VendorInvoiceLines entities. Headers are written before lines, and only while the invoice is unposted, because the header entity rejects writes after posting. Vendor accounts and procurement categories are mapped first so every line lands on a valid record. The Tradeshift document UUID is the idempotency key, so re-reading the same document is safe, while D365 OData writes have no key and rely on natural keys, so a duplicate invoice number is caught and handled rather than re-created. D365 service protection returns HTTP 429 with Retry-After, so ml-connector backs off and retries, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized industrial distributor with around 400 staff runs Microsoft Dynamics 365 F&O for procurement and finance and asks its larger suppliers to deliver invoices through Tradeshift. Before the integration, the AP team opened each invoice in the Tradeshift inbox, read off the supplier, amounts, and line detail, and typed it into D365 as a vendor invoice by hand, which slowed approvals and let typos through. With Microsoft Dynamics 365 F&O and Tradeshift connected, each UBL invoice the supplier sends becomes a vendor invoice header and lines in D365 automatically, matched to the right vendor account, and confirmed purchase orders flow back out to the same suppliers. AP reviews and posts rather than re-keys, and the manual transcription step is gone.

What you can do

• •Read supplier invoices from the Tradeshift inbox as UBL XML and create vendor invoice headers and lines in Microsoft Dynamics 365 F&O before posting.
• •Send confirmed Dynamics 365 F&O purchase orders to Tradeshift as UBL order documents so suppliers receive them on the network.
• •Map Tradeshift tenant UUIDs and UBL parties to D365 vendor accounts and procurement categories so every line lands on a valid record.
• •Bridge Tradeshift OAuth 1.0a request signing and the Microsoft Entra ID client-credentials token D365 requires.
• •Poll the Tradeshift changedAfter document list on your schedule, with retries on D365 rate limits and a full audit trail on every record.

Questions

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

Both directions, by document type. Supplier invoices and credit notes move from Tradeshift into D365 as vendor invoice headers and lines, while confirmed purchase orders move from D365 out to Tradeshift as UBL order documents. Vendor invoices are written only before they are posted, since the D365 header entity rejects changes after posting.

How does the integration handle the different authentication on each side?

Tradeshift own-account access uses OAuth 1.0a, which signs every request with HMAC-SHA1 and requires the X-Tradeshift-TenantId header, while D365 uses an OAuth 2.0 bearer token from Microsoft Entra ID. ml-connector stores both credential sets encrypted, signs each Tradeshift call, and refreshes the D365 token when a request returns 401.

Does Tradeshift send webhooks, or does ml-connector poll?

Tradeshift has no traditional webhook that posts a signed JSON payload to a URL; its only push option is a protobuf event stream that requires a registered App Store plugin. For a server-side connector, ml-connector polls the document list with the changedAfter filter on a schedule you set, so new supplier invoices are picked up without app registration.