Microsoft Dynamics 365 F&O and FedEx integration
Microsoft Dynamics 365 F&O runs finance, procurement, and supply chain. FedEx handles shipping, tracking, and freight. Connecting the two turns a confirmed sales order in D365 into a FedEx shipment with a printed label, then carries the tracking number, transit scans, and delivery confirmation back onto the originating order. FedEx is a carrier API with no invoice or general ledger of its own, so the integration is built around what FedEx actually does: create shipments, return labels and tracking numbers, and push status events. ml-connector handles the different APIs on each side and keeps order fulfillment and shipment visibility in step.
What moves between them
The primary flow runs from Microsoft Dynamics 365 F&O into FedEx. ml-connector reads sales orders that are confirmed and ready to ship, calls the FedEx Ship API to create the shipment and label, and stamps the D365 sales order number and customer invoice number into the FedEx customerReferences array as P_O_NUMBER and INVOICE_NUMBER. FedEx returns the master tracking number, which ml-connector writes back onto the D365 order. Status then flows the other direction: FedEx tracking events, either pulled from the Track API or pushed by Advanced Integrated Visibility webhooks, update delivery status and scan history on the matching order. FedEx holds no financial records, so no invoices or GL entries move between the systems.
How ml-connector handles it
ml-connector stores both credential sets encrypted and runs two OAuth client-credentials flows: one against Microsoft Entra ID using the tenant ID, environment host, client ID, and secret, and one against FedEx using the API key and secret. Both one-hour bearer tokens are cached and reused, which matters most for FedEx because its IP-level auth throttle returns a 403 for ten minutes after a burst of token requests. D365 is pull-first: ml-connector polls confirmed sales orders on a schedule and can also subscribe to the sales-order-confirmed Business Event, but since that payload is only a stub it calls back to OData for the full order before shipping. The D365 sales order number maps to FedEx customerReferences so the shipment can later be found by reference, and the returned tracking number maps back onto the order. Inbound, the FedEx fdx-signature header is verified as HMAC-SHA256 of the body before any event is processed, and the tracking number deduplicates repeat deliveries. Real edge cases handled: D365 returns HTTP 429 with Retry-After under service protection, FedEx returns 429 under its own rate limits, the tenant-specific D365 host is treated as a credential, and the first OData call after an AOS restart can take 30 to 60 seconds, so ml-connector backs off and retries on each side. Every record carries a full audit trail and can be replayed if a downstream call fails.
A real-world example
A mid-sized industrial parts distributor with around 250 employees runs Microsoft Dynamics 365 F&O for order management, inventory, and finance, and ships several hundred parcels a day through FedEx. Before the integration, warehouse staff rekeyed each confirmed order into FedEx Ship Manager, copied the tracking number back into D365 by hand, and fielded customer calls by looking up packages one at a time on the FedEx website. With the two systems connected, every confirmed sales order generates a FedEx label automatically with the order and invoice numbers attached, the tracking number lands on the order, and delivery scans flow back so customer service can see status inside D365. The double entry disappears and shipping errors from manual address typing drop.
What you can do
- Create FedEx shipments and labels directly from confirmed Microsoft Dynamics 365 F&O sales orders.
- Stamp the D365 order and invoice numbers into FedEx customerReferences so every package links back to its order.
- Write the FedEx master tracking number, transit scans, and delivery confirmation onto the matching D365 sales order.
- Bridge Microsoft Entra ID client-credentials auth with FedEx OAuth, caching both bearer tokens to avoid the FedEx auth throttle.
- Verify the fdx-signature HMAC on every tracking webhook and poll the Track API as a backstop, with retries and a full audit trail.
Questions
- Which direction does data move between Microsoft Dynamics 365 F&O and FedEx?
- Order data moves from D365 into FedEx, and shipment status moves from FedEx back into D365. Confirmed sales orders become FedEx shipments and labels, and the returned tracking number plus delivery scans are written back onto the originating order. FedEx has no invoice or general ledger, so no financial records move between the systems.
- Can FedEx post freight invoices or charges into the Dynamics 365 F&O general ledger?
- No. FedEx is a carrier API with no AP invoice, GL account, or vendor entity, and FedEx Billing Online has no public REST API. What FedEx does return is the rated shipment charges and the order and invoice reference numbers on each shipment, which ml-connector can attach to the D365 order for reconciliation, but it does not post journal entries into the ledger.
- How does the integration handle FedEx tracking webhooks and the FedEx auth throttle?
- FedEx Advanced Integrated Visibility pushes tracking events to a callback URL with an HMAC-SHA256 fdx-signature header, which ml-connector verifies before processing and deduplicates by tracking number. Because FedEx throttles OAuth token generation at the IP level and returns a 403 on bursts, ml-connector caches the one-hour bearer token and reuses it rather than authenticating per call, and falls back to polling the Track API where the paid webhook service is not enabled.
Related integrations
More Microsoft Dynamics 365 F&O integrations
Other systems that connect to FedEx
Connect Microsoft Dynamics 365 F&O and FedEx
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started