Oracle E-Business Suite and FedEx integration

What moves between them

Data flows from Oracle E-Business Suite outbound to FedEx and then back to EBS. Purchase order headers and line details flow from EBS into FedEx to create shipments. After shipment creation, tracking numbers, label references, and shipping status are polled from FedEx on a schedule and recorded back into EBS receiving modules and purchase order history. Vendor and item master data from EBS is referenced to validate shipment details against PO requirements.

How ml-connector handles it

ml-connector polls Oracle E-Business Suite on a configurable schedule to identify purchase orders ready to ship, filtered by PO status and ship date. For each eligible PO, it extracts vendor, item, and quantity details and assembles a FedEx shipment request. Authentication to FedEx uses OAuth 2.0 client credentials, and ml-connector caches the bearer token (1-hour TTL) to avoid exceeding FedEx token rate limits (3 tokens per second). After creating a shipment in FedEx, the transactionId is used for deduplication on retries. ml-connector then polls the FedEx Track API on a schedule matching your shipping cycle to retrieve tracking events and status, and posts that data back into EBS purchase order history and receiving modules. Because FedEx applies API rate limits (1,400 transactions per 10 seconds per project), ml-connector backs off and retries failed calls. EBS session tokens expire (typically 30-60 minutes), so ml-connector re-authenticates on 401 responses. All shipment and tracking records carry a full audit trail and can be replayed if a downstream write fails.

A real-world example

A mid-sized distribution company runs Oracle E-Business Suite to manage purchase orders, vendors, and inventory across multiple warehouses. Previously, procurement staff entered purchase orders in EBS, then manually called FedEx or logged into the carrier portal to create shipments, and separately updated EBS with tracking numbers from FedEx emails or manual lookups. This created delays, duplicate data entry, and month-end discrepancies between inventory received in EBS and goods actually shipped. With Oracle E-Business Suite and FedEx connected, new purchase orders trigger automated shipment creation in FedEx with all item and vendor details, and tracking data flows back to EBS in real time, so receiving staff see current status and the finance team has auditable proof of what shipped when.

What you can do

• •Poll Oracle E-Business Suite purchase orders on a schedule and create matching shipments in FedEx with item, quantity, and destination details.
• •Retrieve FedEx tracking numbers and shipping status and write them back into EBS purchase order history and goods receipt records.
• •Authenticate to both systems using their native credentials (EBS HTTP Basic Auth or session token, FedEx OAuth 2.0), and refresh tokens when they expire.
• •Handle FedEx API rate limits and token rate limits with backoff and retry, and use transactionId for client-side deduplication on the Ship API.
• •Maintain a full audit trail on all purchase orders, shipments, and tracking records, with replay capability if a downstream write fails.

Questions

Which direction does data move between Oracle E-Business Suite and FedEx?

Data flows outbound from EBS to FedEx (purchase orders become shipments) and inbound from FedEx back to EBS (tracking and status updates are written to PO history and receiving modules). Item and vendor master data from EBS is read to validate shipment details against the PO, but FedEx does not feed back master data to EBS.

How does the integration handle Oracle EBS session token expiry and FedEx OAuth 2.0 rate limits?

ml-connector obtains an EBS session token and re-authenticates on any 401 response, since tokens expire after 30-60 minutes. For FedEx, it caches the OAuth 2.0 bearer token with a 1-hour TTL to stay under the token rate limit of 3 tokens per second. If a token request would breach that rate limit, ml-connector backs off and retries.

What happens if a shipment is created in FedEx but the write back to EBS fails?

Every shipment creation and tracking poll carries a unique transactionId (FedEx) or internal identifier (EBS), allowing the record to be replayed from the audit trail when the downstream system is available again. No duplicate shipments are created because ml-connector deduplicates on transactionId before retrying.