Infor CloudSuite and UPS integration

What moves between them

Purchase orders and items move from CloudSuite into UPS as shipment creation requests or rating queries. After UPS creates a shipment or provides a rate, the carrier number, tracking ID, and cost are written back to CloudSuite purchase order records. Tracking events flow from UPS back into CloudSuite via the Track Alert API (when subscribed) or Quantum View polling, so procurement and logistics teams see in-transit visibility. The data flow is read-heavy from UPS (tracking is the primary value) and write-light to CloudSuite (shipment creation happens once per order).

How ml-connector handles it

ml-connector stores both OAuth credential sets encrypted. On the CloudSuite side, it accepts the full per-customer ION base URL and tenant ID from .ionapi credentials, and refreshes the bearer token before it expires (configurable 1-24 hour window). On the UPS side, it authenticates with client credentials and refreshes the shorter-lived token (4 hours) on each rate or shipment call, respecting the 250 daily token request limit. When CloudSuite rate limits (typically 100-500 req/min) return 429, ml-connector backs off and retries. Address validation on the UPS side is run before shipment creation to catch misaddressed orders early. UPS Track Alert subscriptions expire after 14 days and must be renewed to maintain webhook push; ml-connector tracks subscription expiry and re-subscribes transparently. Because CloudSuite purchase orders may not have all UPS-required fields (e.g., shipper phone, weight per item), mappings include sensible defaults and validation gates that flag incomplete orders before submission to avoid UPS rejections.

A real-world example

A mid-sized distributor runs Infor CloudSuite M3 for procurement and inventory across three warehouses. When a purchase order is created in CloudSuite, logistics staff currently email the PO details to the UPS account manager or re-enter line items into the UPS portal, then check UPS Tracking manually every few hours for inbound delivery status. With CloudSuite and UPS connected, each purchase order with a supplier that uses UPS is automatically submitted for a rate quote, and once approved, a shipment is created and tracked. Inbound tracking milestones (picked up, in transit, out for delivery, delivered) appear in CloudSuite, so the receiving team knows exactly when goods will arrive and can schedule receiving dock time.

What you can do

• •Create UPS shipments from Infor CloudSuite purchase orders and get back carrier tracking numbers and expected delivery dates.
• •Validate shipping addresses against UPS address databases before submitting shipments to prevent rejections.
• •Retrieve UPS shipment rates and track inbound goods in real time via Track Alert subscriptions or Quantum View polling.
• •Refresh both OAuth credential sets on schedule and handle short-lived UPS tokens (4 hours) and long-lived CloudSuite tokens (1-24 hours).
• •Map CloudSuite purchase order line items to UPS shipment packages, with sensible defaults for missing weight or dimension data and a full audit trail.

Questions

Which direction does data move between Infor CloudSuite and UPS?

The primary flow is CloudSuite to UPS. Purchase orders and items are submitted as shipment creation requests or rating queries, and tracking numbers, rates, and tracking events flow back into CloudSuite. UPS is read-heavy for visibility (tracking status updates multiple times per day), while CloudSuite writes are one-time (shipment creation per order).

How does ml-connector handle the different token lifetimes for CloudSuite and UPS?

CloudSuite tokens are long-lived (1-24 hours, configurable by tenant admin) and ml-connector proactively refreshes before expiry using the .ionapi credentials. UPS tokens are short-lived (approximately 4 hours) and ml-connector refreshes on every rate or shipment call. The system respects the 250 daily UPS token request limit by batching operations and avoiding unnecessary refreshes.

What happens if a CloudSuite purchase order is missing UPS-required fields like weight or shipper phone?

ml-connector validates every order before submission and applies sensible defaults (e.g., package weight from item master or a warehouse-wide default, shipper phone from CloudSuite supplier contact). If critical fields cannot be filled, the order is flagged for manual review in the audit trail instead of rejected silently, so the receiving team can intervene before a shipment fails at UPS.