Infor CloudSuite and ShipStation integration

What moves between them

Purchase orders flow from Infor CloudSuite into ShipStation as inbound shipments or reference records tied to the carrier network. When ShipStation confirms a shipment and generates tracking data, ml-connector reads the shipment details and posts them back to CloudSuite as purchase order receipts (PPS300MI) or inventory goods receipts (MMS471MI), depending on the order type. Inventory items (MMS200MI) are synced in both directions to keep item master and available stock aligned.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the CloudSuite side, it reads the tenant-specific base URL and OAuth endpoint from the customer's .ionapi file, then authenticates with service account credentials and refreshes the bearer token before expiry (token lifetime varies per tenant, typically 1-24 hours). On the ShipStation side, it presents the API Key in the V2 request header and respects the 200 requests/min rate limit by tracking X-Rate-Limit-Remaining. CloudSuite purchase orders are polled via PPS100MI with a modified-date filter (no webhooks available), and new ShipStation shipments are detected through both webhook SHIP_NOTIFY events and periodic polling with modifyDate. When a shipment is received, ml-connector maps the ShipStation tracking number and carrier to the CloudSuite PO reference and posts the receipt. CloudSuite M3 requires a CONO (company number) parameter, which is stored per customer and prepended to every M3 call. If a shipment notification fails to post (CloudSuite returns 429 or a transient error), the record is enqueued for retry with exponential backoff.

A real-world example

A mid-sized supplier operates Infor CloudSuite M3 for procurement and inventory across three warehouses. They use ShipStation to consolidate inbound shipments from multiple vendors into a single carrier network. Before the integration, receiving staff manually matched shipments that arrived against purchase orders in CloudSuite, often receiving carriers' tracking PDFs via email and re-entering receipt dates and quantities by hand. Warehouse managers could not see in-transit stock until the shipment was physically received and scanned. With Infor CloudSuite and ShipStation connected, each vendor shipment is reflected in ShipStation as soon as the carrier accepts the parcel, ml-connector automatically posts the receipt to CloudSuite tied to the original PO, and the inventory system shows in-transit stock in real time. Receiving staff scan labels and confirm quantities, and the transaction is complete in both systems.

What you can do

• •Sync purchase orders from Infor CloudSuite to ShipStation as inbound shipments, mapped to vendor and carrier.
• •Post shipment confirmations and tracking data from ShipStation back to CloudSuite as goods receipts linked to the original purchase order.
• •Keep inventory item master (MMS200MI) aligned between CloudSuite and ShipStation so available stock reflects committed shipments.
• •Authenticate Infor CloudSuite with OAuth2 and tenant-specific URL from the .ionapi file, and ShipStation with API Key header authentication.
• •Poll CloudSuite for purchase orders and ShipStation for shipment updates on a schedule, with retries on failure and a full audit trail on every receipt.

Questions

How does ml-connector handle Infor CloudSuite's tenant-specific authentication and base URL?

Each CloudSuite customer has a unique base URL and tenant ID in their .ionapi credentials file, along with OAuth 2.0 service account client ID and secret. ml-connector reads the .ionapi file to extract the token endpoint and base URL, then authenticates with the service account credentials. Token lifetime varies per tenant (1-24 hours), so ml-connector proactively refreshes the bearer token before expiry to prevent outages.

Why does ml-connector poll Infor CloudSuite if ShipStation supports webhooks?

Infor CloudSuite has no native webhooks for cloud connector use - purchase order updates are available only through polling the PPS100MI list endpoint with a modified-date filter. ShipStation does publish webhooks (SHIP_NOTIFY), but the webhook payload contains only a pointer to the shipment, not the full data. ml-connector polls both systems to ensure no shipments are missed and to detect purchase order updates that ShipStation is not aware of.

What happens when a goods receipt fails to post to Infor CloudSuite due to a network error or rate limit?

ml-connector enqueues the receipt for retry with exponential backoff and jitter. The receipt is marked with a retry count and timestamp so ml-connector can distinguish retries from new shipments. Each retry carries the full audit trail of the original shipment, and the operator can replay or investigate any receipt that exhausts all retries without posting.