Microsoft Dynamics 365 Business Central and Stedi integration

What moves between them

Documents flow in both directions. On the outbound side, ml-connector reads purchase orders and posted invoices from Business Central and sends them as JSON to Stedi, which generates the 850 and 810 EDI and delivers them to the right partner connection. On the inbound side, Stedi parses incoming EDI such as 850 purchase orders, 855 acknowledgments, and 810 invoices from partners and posts the JSON to ml-connector, which creates or updates the matching purchase orders, sales orders, and invoices in Business Central. Vendor, customer, and item references are aligned so each EDI line resolves to a real Business Central record. Cadence is event driven inbound and scheduled or webhook-triggered outbound.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Business Central it requests an Entra ID client-credentials token against the tenant and refreshes it when a call returns 401, and it builds the base URL from the stored environment name and company id. For Stedi it sends the API key in the Authorization header on every call. Outbound, it reads Business Central documents, builds the JSON Stedi expects, and POSTs to the generate-edi endpoint with an Idempotency-Key so a network retry does not produce a duplicate EDI file; control numbers are left for Stedi to assign. Inbound, the Stedi transaction.processed.v2 webhook has a hard five-second timeout, so ml-connector returns 2xx immediately, dedupes on the eventId, then fetches the full payload from the documentDownloadUrl with the API key and writes it to Business Central asynchronously. Posting an invoice is a two-step operation, since a POSTed draft must be posted with the Microsoft.NAV.post bound action. Webhook subscriptions in Business Central expire after three days, so the connector renews them before expiry and falls back to polling for purchaseOrders, which Business Central does not push. Trading-partner partnerships and transaction settings are configured once in the Stedi portal, since there is no public API to create them. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized consumer goods manufacturer with around two hundred staff runs Microsoft Dynamics 365 Business Central for purchasing, inventory, and finance, and sells into large retailers that mandate EDI. Before the integration, a coordinator rekeyed each retailer purchase order from a partner portal into Business Central as a sales order, then typed the invoice back out into the retailer's EDI tool, which was slow and produced chargebacks when a line or quantity was mistyped. With Business Central and Stedi connected, inbound 850 orders arrive as Business Central sales orders automatically and 810 invoices go back out as EDI from the posted invoice, so orders are acknowledged within the partner's window and the rekeying and the compliance chargebacks are gone.

What you can do

• •Send Microsoft Dynamics 365 Business Central purchase orders and invoices to Stedi as 850 and 810 EDI for trading partners.
• •Turn inbound EDI parsed by Stedi into Business Central purchase orders, sales orders, and invoices.
• •Bridge Entra ID OAuth client credentials on Business Central and the Stedi API key, refreshing the token on expiry.
• •Dedupe outbound EDI with an Idempotency-Key and inbound webhooks with the Stedi eventId before writing.
• •Renew three-day Business Central webhook subscriptions and poll purchaseOrders, with retries and a full audit trail.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and Stedi?

Both directions. Outbound, ml-connector reads purchase orders and posted invoices from Business Central and sends them to Stedi to generate 850 and 810 EDI for partners. Inbound, Stedi parses incoming EDI and posts the JSON to ml-connector, which creates or updates the matching purchase orders, sales orders, and invoices in Business Central. Stedi holds no business records, so Business Central stays the system of record.

How does ml-connector receive inbound EDI from Stedi?

Stedi pushes the transaction.processed.v2 webhook when it finishes parsing an inbound transaction. The endpoint has a hard five-second timeout, so ml-connector returns 2xx right away and processes the payload asynchronously. It dedupes on the event id, then fetches the full translated JSON from the documentDownloadUrl, which requires the Stedi API key, before writing the records into Business Central.

Why does the integration still poll Business Central if it supports webhooks?

Business Central webhook subscriptions expire after three days and must be renewed, and purchaseOrders is not in the webhook-supported list. ml-connector renews the active subscriptions before they expire and polls with an OData lastModifiedDateTime filter for entities that cannot be pushed. Each Business Central notification only signals a change, so the connector fetches the actual record after every event.