ml-connector
Microsoft Dynamics 365 Business CentralFedEx

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.

How Microsoft Dynamics 365 Business Central works

Microsoft Dynamics 365 Business Central exposes vendors, customers, sales orders, sales invoices, items, shipment methods, and GL data through its REST API v2.0, built on OData v4, with every resource nested under a company on a tenant and environment specific base URL. It authenticates with Microsoft Entra OAuth 2.0 client credentials (tenant ID, client ID, client secret, environment name) for unattended access. It supports push webhook subscriptions that signal a change and carry a shared clientState value, but those notifications carry no payload, expire after three days, and are not offered for purchaseOrders, so the connector fetches the changed record and uses lastModifiedDateTime filtering for incremental reads.

How FedEx works

FedEx exposes a REST carrier platform for shipping, tracking, rates, and freight. The Ship API creates and validates shipments and returns a master tracking number and a base64 label; the Track API looks up packages by tracking number or by reference types including INVOICE and PURCHASE_ORDER. It authenticates with an OAuth 2.0 client-credentials bearer token (API key, API secret, account number) valid for one hour, and token caching is mandatory because auth generation is throttled at the IP level. Near-real-time delivery events are available through the paid Advanced Integrated Visibility webhook, which signs each POST with an HMAC-SHA256 fdx-signature header. FedEx has no vendor, invoice, or GL objects, so order context is carried in the customerReferences array.

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

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