Sage 300 and FedEx integration

What moves between them

The main flow runs from Sage 300 into FedEx. ml-connector polls Sage 300 Order Entry for new or ready-to-ship orders on a cadence you define (e.g., every 4 hours or daily at night), maps each order line to a FedEx shipment with address and weight pulled from Sage 300 customer records and inventory, and submits the shipment to FedEx for label generation. FedEx returns a tracking number, which ml-connector stores encrypted in Sage 300 and maps to the order. The return flow pulls FedEx tracking events (In Transit, Delivered, Exception) from the free Track API and updates Sage 300 order status, so your fulfillment team sees delivery confirmation without leaving the ERP. Address validation happens on the Sage 300 side (Sage must have valid customer city and country); FedEx validates the full address at label-create time and may reject or flag high-risk addresses for manual review.

How ml-connector handles it

ml-connector stores both Sage 300 credentials (username and password, uppercase as required by Sage) and FedEx OAuth credentials (client_id and secret) encrypted. On the Sage 300 side, it includes Basic Auth on every request and polls OEOrders using $filter on DocumentDate to find new orders since the last sync; it uses $skip and $top for pagination since Sage 300 offers no cursors. On the FedEx side, it obtains an OAuth token once and caches it for the full 1-hour TTL, refreshing only on token expiry or 401 response; it backs off and retries on 429 or 403 (rate limit) responses. When syncing a Sage 300 order to FedEx, it looks up the customer address from ARCustomers and item weight from ICItems, builds a FedEx Create Shipment request, and stores the returned tracking number in Sage 300 (encrypted, since it links to a customer shipment). For tracking pulls, it collects all undelivered tracking numbers from Sage 300 and sends them in batches of up to 30 to FedEx Track API, mapping returned events (In Transit, Delivered, etc.) back to the order and updating the Sage 300 Order Entry record. FedEx has no server-side idempotency, so ml-connector uses FedEx's transactionId field for client-side deduplication so re-runs do not create duplicate shipments. Every record carries a full audit trail: order polled, shipment created in FedEx, tracking returned, status updated in Sage 300.

A real-world example

A mid-sized wholesale distributor runs Sage 300 for order entry, inventory management, and AR. The warehouse ships 500-1,000 orders per week via FedEx, and the fulfillment team has spent 2-3 hours daily printing packing lists from Sage, manually entering customer addresses into FedEx Ship Manager, generating labels, and updating order status back in Sage 300 by hand. Peak season (Q4) overloads the team and orders ship late. With Sage 300 and FedEx connected, confirmed orders automatically create FedEx labels overnight, and the team prints pre-labeled packages the next morning. Tracking scans flow back into Sage 300 in real-time, so the fulfillment team sees In Transit and Delivered status without re-keying, and the finance team closes AR invoices with automatic proof of delivery from FedEx. The 2-3 hour manual process drops to 20 minutes of label review, and peak-season order-to-ship time shrinks from 3 days to 1.

What you can do

• •Poll Sage 300 Order Entry on a scheduled cadence and create FedEx shipments for ready-to-ship orders with addresses and item weights from Sage 300 master data.
• •Retrieve FedEx tracking numbers and store them encrypted in Sage 300, linking each shipment to the customer order.
• •Pull FedEx tracking events (In Transit, Delivered, Exception) and update Sage 300 order status so fulfillment visibility never requires manual re-keying.
• •Authenticate Sage 300 with HTTP Basic Auth (uppercase credentials) and FedEx with OAuth 2.0, with token caching to respect FedEx IP-level rate limits.
• •Deduplicate shipments client-side using FedEx's transactionId field, maintain a full audit trail of every order polled and shipment created, and replay failed records if a downstream call fails.

Questions

Which direction does data move between Sage 300 and FedEx?

The main flow is Sage 300 into FedEx. Customer orders and fulfillment-ready status from Sage 300 trigger shipment creation in FedEx. Tracking events (In Transit, Delivered) flow back from FedEx into Sage 300 order status. Addresses and item weights are read from Sage 300 master data (ARCustomers and ICItems) and sent to FedEx; FedEx validates the address at label-create time and may reject or flag for manual review if the address is undeliverable.

How does ml-connector handle Sage 300's polling requirement and lack of webhooks?

Sage 300 has no webhooks or change-data-capture, so ml-connector polls the OEOrders endpoint on a cadence you define (e.g., every 4 hours or once daily at night), using OData $filter on DocumentDate to find new orders since the last sync. It uses $skip and $top for pagination. FedEx offers paid webhooks for tracking (Advanced Integrated Visibility), but ml-connector defaults to the free Track API, which accepts up to 30 tracking numbers per call and returns the latest event for each.

How does the integration respect FedEx's rate limits and the uppercase username requirement in Sage 300?

FedEx rate-limits at 1,400 transactions per 10 seconds and at 3 OAuth tokens per second at the IP level (403 for 10 min if exceeded). ml-connector obtains a bearer token once and caches it for the full 1-hour TTL, refreshing only on expiry, and backs off and retries on 429 or 403 to stay within limits. Sage 300 requires uppercase username and password in all Basic Auth headers; ml-connector enforces uppercase on credential entry and includes that auth header on every Sage 300 request without modification.