Infor CloudSuite and SPS Commerce integration

What moves between them

The main flow runs from Infor CloudSuite outbound to SPS Commerce. Supplier master records (company name, address, contact, tax ID) are polled from CloudSuite and posted to SPS Commerce for provisioning to retail trading partners. Purchase orders and invoices flow the same direction, transformed into RSX 7.7.7 JSON and routed to the correct trading partner based on your SPS onboarding configuration. Inbound documents (PO acknowledgments, advance ship notices, inventory adjustments) are polled from SPS Commerce at regular intervals and matched back to the originating purchase order or invoice in CloudSuite for audit and exception handling.

How ml-connector handles it

ml-connector stores OAuth credentials for both systems encrypted. On the CloudSuite side, it uses the customer-provided base URL and tenant ID from the .ionapi file, obtains a bearer token via the OAuth Resource Owner Password Credentials flow, and polls the M3 or SyteLine REST APIs (CRS620MI for suppliers, PPS100MI/PPS200MI for purchase orders, APS100MI for invoices) by modified date. Tokens are refreshed proactively before the tenant-configured lifetime expires (typically 1-24 hours). On the SPS Commerce side, ml-connector authenticates via OAuth client credentials, obtains a JWT bearer token, and polls /fulfillment/v1/purchaseorders and /fulfillment/v1/invoices at configurable intervals (5-15 minutes). Outbound CloudSuite records are transformed into RSX 7.7.7 JSON envelopes with the correct trading partner wrapper based on the SPS onboarding manifest. Inbound documents from SPS are parsed, deduplicated by document number at the application layer, and matched to CloudSuite purchase orders or invoices by reference number for reconciliation. Both systems rate limit; ml-connector implements exponential backoff with jitter on 429 responses. Every record carries a full audit trail linking the CloudSuite source document to its SPS envelope and any inbound receipt.

A real-world example

A mid-market consumer goods supplier manufactures and distributes products across three distribution centers and sells to Walmart, Target, and Amazon through an SPS Commerce onboarding. Previously, the supply chain team exported purchase orders from CloudSuite, formatted them as X12 850 files in a separate EDI tool, uploaded them to an SFTP site, and manually tracked confirmations in a spreadsheet. When retail partners rejected shipments for missing or malformed advance ship notices, the team had to re-key the exception into CloudSuite and resubmit. With CloudSuite and SPS Commerce connected, every purchase order flows automatically into SPS in the correct EDI format, advance ship notices are generated from CloudSuite shipment records and delivered on time, and inbound PO acknowledgments and ASNs automatically update the corresponding CloudSuite records. The manual spreadsheet tracking is gone, and exceptions are caught immediately.

What you can do

• •Poll supplier master records from Infor CloudSuite and provision them to SPS Commerce for onboarded trading partners.
• •Sync purchase orders and invoices from CloudSuite outbound to SPS Commerce, transformed into RSX 7.7.7 JSON envelopes and routed by trading partner.
• •Receive purchase order acknowledgments and advance ship notices from SPS Commerce and reconcile them against CloudSuite purchase orders and shipments.
• •Authenticate both systems via OAuth 2.0, manage token refresh per system lifetime, and handle per-customer CloudSuite tenant URLs and credentials from .ionapi files.
• •Poll inbound EDI transactions at configurable intervals, deduplicate by document number, and maintain a full audit trail linking CloudSuite source records to SPS Commerce envelopes and receipts.

Questions

Which direction does data flow between Infor CloudSuite and SPS Commerce?

The primary flow is outbound from CloudSuite to SPS Commerce. Supplier master records, purchase orders, and invoices are polled from CloudSuite and posted to SPS Commerce for relay to retail trading partners. Inbound documents (PO acknowledgments, advance ship notices, inventory advice) are polled from SPS Commerce and reconciled against CloudSuite records for audit and visibility. Reference data such as supplier lists and trading partner identifiers flow both directions.

How does ml-connector handle the different authentication and rate-limiting requirements between CloudSuite and SPS?

ml-connector stores encrypted credentials for both systems and maintains separate OAuth sessions. For CloudSuite, it uses the customer-specific base URL and tenant ID to obtain a bearer token via the Resource Owner Password Credentials flow, and refreshes it proactively before the tenant-configured expiry (1-24 hours). For SPS Commerce, it authenticates via OAuth client credentials to obtain a JWT token. Both systems rate limit; ml-connector respects 429 responses and backs off with exponential jitter.

What happens when a CloudSuite purchase order arrives at SPS while a retail partner is not yet onboarded, or a trading partner ID changes?

Trading partner IDs and onboarding status are determined during SPS Commerce setup and are not discoverable via API. ml-connector uses a provisioned manifest that maps CloudSuite customers or business units to SPS trading partner IDs. If a purchase order references a trading partner not in the manifest, ml-connector flags it for manual review in the audit trail rather than silently dropping it, so exceptions can be resolved before the next sync cycle. Changes to trading partner mappings require a manifest update but do not interrupt the sync process.