IFS Cloud and FedEx integration

What moves between them

Purchase orders and sales orders flow from IFS Cloud to FedEx for shipment creation and rate quoting. When a PO is marked ready-to-ship in IFS, ml-connector reads the order, creates a shipment in FedEx, and writes the FedEx label and tracking number back to the IFS purchase order record. Tracking updates flow from FedEx back to IFS either via FedEx webhook (if enabled) or by polling the Track API on a schedule aligned with your shipment window. GL accounts and cost centers in IFS are preserved during this exchange; shipping costs and tracking status land on the correct financial dimensions.

How ml-connector handles it

ml-connector maintains separate OAuth2 token caches for IFS and FedEx, refreshing each when needed (IFS tokens expire in 60 minutes, FedEx tokens are cached for 1 hour minimum to avoid rate-limit throttling). On the IFS side, every PATCH to a purchase order or sales order first reads the current ETag header, then includes that ETag on the update to satisfy optimistic concurrency; if the record changed in the meantime, IFS returns 412 Precondition Failed and ml-connector retries with the fresh ETag. When creating shipments in FedEx, ml-connector includes the PO or SO number as a client reference and stores the FedEx transactionId for dedup if the request is retried. Polling respects FedEx IP-level token rate limits (3 tokens per second over 5 seconds triggers a 10-minute block), so token requests are batched. Tracking data pulled from FedEx is written to IFS purchase order line items and cross-referenced to GL accounts so shipping status appears in finance reports. All operations are logged with full record history and can be replayed if a downstream failure occurs.

A real-world example

A mid-sized manufacturing company runs IFS Cloud for procurement and supply chain. They place purchase orders for raw materials with dozens of suppliers and use FedEx for inbound and outbound freight. Before the integration, operations staff checked FedEx tracking and the IFS PO system separately, and wrote tracking numbers and estimated arrival dates into IFS by hand. Finance had no visibility into freight costs until the FedEx invoice arrived weeks after delivery. With IFS Cloud and FedEx connected, each shipment created in IFS automatically generates a FedEx label, and tracking updates flow back into the PO so the warehouse, operations, and finance teams work from a single source of truth. Month-end closing includes actual freight costs tied to the correct GL accounts and cost centers automatically.

What you can do

• •Create FedEx shipments from IFS purchase orders and sales orders, with automatic label generation and tracking number capture.
• •Push actual freight costs and tracking status back to IFS GL accounts so finance reports include shipping expense in the correct cost center.
• •Poll FedEx tracking via the Track API on a configurable schedule, or subscribe to FedEx Advanced Integrated Visibility webhooks for real-time push (paid).
• •Handle ETag concurrency on every IFS record mutation and OAuth2 token refresh for both systems without manual intervention.
• •Maintain a complete audit trail of every shipment, rate quote, and tracking update, with the ability to replay failed operations.

Questions

Which direction does data move between IFS Cloud and FedEx?

The main flow is from IFS Cloud to FedEx. Purchase orders and sales orders in IFS trigger shipment creation in FedEx. Tracking data, rate quotes, and shipping status flow from FedEx back into IFS purchase orders and GL accounts. Cost centers and GL dimensions in IFS are preserved during the exchange so shipping costs land on the correct financial accounts.

How does ml-connector handle IFS OData ETag requirements and FedEx rate limiting?

ml-connector reads the ETag header from every IFS record before updating it, then includes that ETag on the PATCH request to satisfy optimistic concurrency. If the record changed, IFS returns 412 and ml-connector retries with the fresh ETag. For FedEx, OAuth tokens are cached for at least 1 hour to avoid IP-level rate-limit throttling (3 tokens per 5 seconds triggers a 10-minute block), and transaction requests are batched.

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

ml-connector stores the FedEx transactionId (for client-side dedup) and the tracking number separately, so if the IFS write fails, the operation can be replayed without creating a duplicate shipment. Every shipment, rate, and tracking update carries a complete audit trail and can be manually replayed if needed.