Microsoft Dynamics 365 Business Central and FedEx integration
Microsoft Dynamics 365 Business Central runs finance, sales, and inventory. FedEx handles shipping labels, transit, and delivery tracking. Connecting the two means a released sales order in Business Central becomes a FedEx shipment without re-keying the address, the tracking number lands back on the order, and delivery scans update fulfillment status in the ERP. FedEx is a carrier system with no vendor master or general ledger, so ml-connector uses the FedEx reference fields to tie every label and tracking event back to the originating Business Central order.
What moves between them
The primary flow runs from Microsoft Dynamics 365 Business Central into FedEx. ml-connector reads released sales orders, their ship-to addresses, and package details, then calls the FedEx Ship API to create a label, stamping the Business Central order number into customerReferences as a P_O_NUMBER or INVOICE_NUMBER. The returned master tracking number is written back onto the sales order. The return flow runs from FedEx into Business Central: tracking scans and delivery events, pulled from the Track API on a schedule or pushed by Advanced Integrated Visibility, update the order so fulfillment status reflects the live package state. FedEx holds no financial records, so ml-connector never posts ledger or invoice data into the carrier.
How ml-connector handles it
ml-connector stores both credential sets encrypted. On the ERP side it requests a Microsoft Entra client-credentials token scoped to the Business Central API and targets the customer's environment name in the base URL. On the carrier side it requests a FedEx bearer token and caches it for its full one-hour life, since FedEx throttles token generation per IP and returns 403 on bursts. Shipment methods in Business Central are mapped to FedEx service types first, so each order resolves to a valid service. Because Business Central does not offer webhooks for purchaseOrders and its other notifications carry no payload, ml-connector polls sales orders with a lastModifiedDateTime filter and follows the odata.nextLink for paging. FedEx has no idempotency-key header, so a stable BullMQ job ID and the stored master tracking number prevent a re-read order from creating a duplicate label. Delivery events arrive either from the Track API poll or, where the paid Advanced Integrated Visibility subscription is active, from a webhook verified against its HMAC-SHA256 fdx-signature before processing. Throttling on either side returns HTTP 429, so failed calls back off and retry, every record carries a full audit trail, and a failed write can be replayed.
A real-world example
A mid-sized industrial supplies distributor with about 150 staff runs Microsoft Dynamics 365 Business Central for sales, inventory, and finance, and ships parcels and pallets through FedEx. Before the integration, a warehouse clerk re-typed each order's ship-to address into the FedEx web tool, then pasted tracking numbers back into Business Central by hand, which slowed dispatch and left customer service guessing at delivery status. With the two connected, a released sales order produces a FedEx label automatically with the order number on it, the tracking number appears on the order, and delivery scans flow back so the support team sees real status. Dispatch is faster, the address typos are gone, and tracking is no longer a manual lookup.
What you can do
- Turn released Microsoft Dynamics 365 Business Central sales orders into FedEx shipping labels without re-keying the ship-to address.
- Stamp the Business Central order number into the FedEx customerReferences array so every label and scan ties back to the source order.
- Write the FedEx master tracking number back onto the originating Business Central sales order.
- Push FedEx tracking scans and delivery events into Business Central so fulfillment status reflects the live package state.
- Bridge Microsoft Entra client-credentials auth and the FedEx bearer token, mapping Business Central shipment methods to FedEx service types.
Questions
- Which direction does data move between Microsoft Dynamics 365 Business Central and FedEx?
- The primary flow is Business Central into FedEx: sales orders and ship-to addresses are read and turned into FedEx shipments, and the master tracking number is written back onto the order. The return flow is FedEx into Business Central, where tracking scans and delivery events update fulfillment status. FedEx has no vendor, invoice, or GL objects, so ml-connector never writes financial data into the carrier.
- How does FedEx tie a shipment back to the right Business Central order?
- FedEx is a carrier API with no ERP records, so the link is carried in the customerReferences array on each shipment. ml-connector stamps the Business Central order or invoice number into a P_O_NUMBER or INVOICE_NUMBER reference at label creation, then matches scans back using the FedEx Track API, which can look up packages by those same INVOICE and PURCHASE_ORDER reference types.
- How are tracking updates delivered, by polling or webhook?
- Both are supported. By default ml-connector polls the FedEx Track API on a schedule, since basic tracking is free and pull-based. Where the customer has the paid Advanced Integrated Visibility subscription, FedEx pushes near-real-time events to a webhook, and ml-connector verifies the HMAC-SHA256 fdx-signature on each POST before posting status into Business Central.
Related integrations
More Microsoft Dynamics 365 Business Central integrations
Other systems that connect to FedEx
Connect Microsoft Dynamics 365 Business Central and FedEx
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started