Oracle Fusion Cloud ERP and FedEx integration

What moves between them

Shipments flow from Oracle Fusion to FedEx. ml-connector reads purchase orders and goods receipts from Oracle Fusion, validates supplier addresses and FedEx account routing, and creates shipments in FedEx with the purchase order number as a reference. Tracking and rate data flow back from FedEx into Oracle Fusion every 5 to 15 minutes via polling. Billing and invoice disputes remain in the FedEx Billing Online portal and do not flow back to Oracle Fusion.

How ml-connector handles it

ml-connector stores OAuth credentials for both systems encrypted and obtains and caches tokens separately to avoid triggering FedEx IP-level rate limits. On the Oracle Fusion side, it polls the REST API using LastUpdateDate to detect new and updated purchase orders, goods receipts, and invoices. On the FedEx side, it routes each shipment to the correct FedEx account number (managed per customer in ml-connector settings), calls the Ship API with a transactionId for client-side deduplication, and polls the Track API every 5 to 15 minutes to read delivery status and push it back into Oracle Fusion as a custom field or audit record. ml-connector respects FedEx's 1,400 transactions per 10 seconds limit by batching Track calls (up to 30 tracking numbers per call) and backing off on 429 responses. Every shipment and tracking event is logged with a full audit trail and can be replayed if an Oracle Fusion update fails.

A real-world example

A mid-market distribution company manages supplier relationships and purchase orders in Oracle Fusion Cloud ERP, with multiple FedEx accounts per region. Previously, the warehouse team shipped goods via FedEx, then manually entered tracking numbers into Oracle Fusion at the end of the day, and month-end reconciliation required chasing down tracking status via FedEx Tracking directly. With Oracle Fusion and FedEx connected, each goods receipt triggers an automatic shipment creation in FedEx, tracking updates flow back into Oracle Fusion on a continuous schedule, and the supply chain team sees real-time carrier status without manual lookups.

What you can do

• •Create FedEx shipments automatically from Oracle Fusion purchase orders and goods receipts, with address and account validation.
• •Poll FedEx tracking every 5 to 15 minutes and update Oracle Fusion with carrier status and estimated delivery dates.
• •Quote FedEx rates for each shipment and store the quote in Oracle Fusion for cost tracking.
• •Route shipments to the correct FedEx account number per customer and region using cached OAuth tokens.
• •Retry failed shipments with exponential backoff and maintain a full audit trail of every shipment, rate quote, and tracking event.

Questions

How does ml-connector handle FedEx's account number and rate limit constraints?

ml-connector stores the FedEx account number per customer in settings and routes each shipment to that account when calling the Ship API. It caches OAuth tokens for one hour to avoid triggering IP-level rate limits (3 tokens per second), and it respects the 1,400 transactions per 10 seconds limit by batching Track calls and backing off on 429 responses.

Does ml-connector push tracking data back to Oracle Fusion in real time?

No. Oracle Fusion has no direct outbound webhooks for standalone connectors, so ml-connector polls FedEx Track API every 5 to 15 minutes to read carrier status and delivery events. FedEx offers paid webhooks (Advanced Integrated Visibility), but polling is sufficient for most supply chain workflows and reduces operational cost.

What happens if a shipment creation fails or a tracking update cannot write to Oracle Fusion?

ml-connector logs the failure with a full audit trail, retries with exponential backoff and jitter, and surfaces unresolved errors via the audit API. The original shipment data is preserved so the update can be replayed once the issue is resolved, either by the customer or by ml-connector support.