Infor CloudSuite and Adobe Commerce integration
Infor CloudSuite runs manufacturing, distribution, and finance. Adobe Commerce runs the online storefront and B2B accounts. Connecting the two means web orders, the invoices captured against them, and refunds flow into Infor CloudSuite without re-keying, while the customer and item masters stay in agreement. ml-connector handles the different APIs on each side and moves the data on a schedule you control. Because Adobe Commerce has no GL account resource, the general ledger stays in Infor CloudSuite where it belongs.
What moves between them
The main flow runs from Adobe Commerce into Infor CloudSuite. ml-connector reads sales orders, the invoices captured against them, and credit memos from Adobe Commerce and posts them into Infor CloudSuite as customer sales and receivables, mapped to the matching Infor items, customers, and accounts. Customer and company records flow the same direction so the Infor customer master reflects storefront buyers and B2B accounts, and product references are aligned so each order line resolves to a real Infor item number. Polling cadence follows the schedule you set, typically every few minutes for orders. GL postings stay in Infor CloudSuite, since Adobe Commerce has no GL resource, so ml-connector never writes ledger entries back to the store.
How ml-connector handles it
ml-connector stores both credential sets encrypted. On the Adobe Commerce side it signs each PaaS request with the OAuth 1.0a consumer and access tokens, or requests and refreshes an IMS OAuth 2.0 bearer token for the Cloud Service before it expires, and it scopes every call to the right store view by URL path or header. On the Infor side it accepts the full tenant base URL, token endpoint, and service account credentials from the .ionapi file, since Infor publishes no shared hostname, and it supplies the CONO company number that most M3 programs require. Because Infor has no self-service webhooks, it polls Adobe Commerce orders, invoices, and credit memos on a schedule rather than waiting for a push, paging through results with searchCriteria and the total_count field. Items and customers are mapped first, so every order line references an Infor item and customer that already exist. Neither side has an idempotency key header, so ml-connector dedupes on the increment_id and a BullMQ jobId, and on the Infor side it queries before each Add call because M3 Add transactions are not idempotent and a duplicate POST creates a duplicate record. It refreshes the Infor token proactively before its one-to-twenty-four-hour expiry rather than reacting to a 401, backs off on HTTP 429 from the ION gateway with jitter, and where Adobe Commerce webhooks are enabled it can take a push as a trigger while keeping the synchronous endpoint fast so storefront operations do not stall.
A real-world example
A mid-sized industrial parts maker runs Infor CloudSuite M3 for production, inventory, and finance, and sells spares to dealers through an Adobe Commerce B2B storefront. Before the integration, a clerk printed each web order and keyed it into Infor by hand, which meant orders sat for hours, item numbers were sometimes typed wrong, and the receivables in the ledger never matched the storefront totals. With Infor CloudSuite and Adobe Commerce connected, each order and its captured invoice flow into Infor within the polling window, allocated to the correct customer and item, and refunds post as credit notes. Orders ship sooner, the keying errors are gone, and the sales accounts reconcile without a month-end scramble.
What you can do
- Post Adobe Commerce sales orders and captured invoices into Infor CloudSuite as customer sales and receivables.
- Map Adobe Commerce SKUs to Infor CloudSuite item numbers so every order line lands on a real part.
- Keep the Infor CloudSuite customer master aligned with Adobe Commerce storefront buyers and B2B company accounts.
- Authenticate Adobe Commerce with OAuth 1.0a or IMS OAuth 2.0, and Infor CloudSuite with its ION OAuth 2.0 token.
- Poll on a schedule with increment_id and jobId dedup, query-before-write on Infor, retries, and a full audit trail.
Questions
- Which direction does data move between Infor CloudSuite and Adobe Commerce?
- The main flow is Adobe Commerce into Infor CloudSuite. Sales orders, invoices, credit memos, and customer records move from Adobe Commerce into Infor, while item and SKU references are aligned so order lines resolve to real parts. Adobe Commerce has no GL account resource, so the general ledger stays in Infor CloudSuite and ml-connector never writes ledger entries back to the store.
- How does ml-connector authenticate to Infor CloudSuite's per-tenant gateway?
- Infor publishes no shared hostname, so ml-connector takes the base URL, token endpoint, client credentials, and service account key and secret from the customer's .ionapi file. It uses the OAuth 2.0 Resource Owner Password grant to obtain a bearer token and refreshes it proactively before its one-to-twenty-four-hour expiry. It also supplies the CONO company number that most M3 API programs require on each call.
- Does Adobe Commerce push orders, or does ml-connector poll for them?
- Polling is the default because Infor CloudSuite has no self-service webhooks to push into. ml-connector reads Adobe Commerce orders, invoices, and credit memos on a schedule, paging with searchCriteria and total_count, and dedupes on the increment_id. Where Adobe Commerce webhooks are enabled it can take a push as a trigger, while keeping the synchronous endpoint fast so storefront operations are not held up.
Related integrations
More Infor CloudSuite integrations
Other systems that connect to Adobe Commerce
Connect Infor CloudSuite and Adobe Commerce
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started