ml-connector
Infor CloudSuiteAdobe Commerce

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.

How Infor CloudSuite works

Infor CloudSuite exposes suppliers, customers, items, purchase orders, supplier invoices, and GL accounts through the Infor ION API Gateway, a REST surface whose base URL, tenant segment, and OAuth token endpoint are unique per customer and come from the downloaded .ionapi credentials file. It authenticates with OAuth 2.0 using the Resource Owner Password grant, combining the registered app's client credentials with a service account key and secret to obtain a bearer token that expires in one to twenty-four hours. Product lines differ in shape: M3 uses transaction-style m3api-rest programs such as CRS610MI and APS100MI, SyteLine uses IDO REST, and LN and FSM mix REST with BOD document flows. Infor has no self-service webhooks, so records are read by polling the REST API or by configuring an ION Desk document flow.

How Adobe Commerce works

Adobe Commerce exposes orders, invoices, credit memos, customers, B2B companies, and products through its REST Commerce Web APIs, with paths under a /V1/ prefix scoped by store view in the URL on PaaS or by header on the Cloud Service. PaaS authenticates with OAuth 1.0a integration credentials or an admin bearer token, while the Cloud Service uses IMS OAuth 2.0 client credentials with tokens that expire in about twenty-four hours. Purchase orders, negotiable quotes, and company accounts require the B2B extension. Adobe Commerce supports synchronous outbound webhooks signed with HMAC-SHA256 and async Adobe I/O Events, but exposes no GL chart-of-accounts resource, so the ledger is left to the ERP.

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

Connect Infor CloudSuite and Adobe Commerce

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started