Infor SX.e to Shopify Integration

It is also, quietly, one of the better documented integration surfaces in wholesale distribution. That is worth knowing before anyone quotes you a custom build, and it is the basis of the answer to the objection you are about to hear.

We ran an SX.e distributor's platform question through a web-connected model twice, identically. Shopify was not recommended in either run. Both defaulted to Infor's own commerce product, both citing Infor's CloudSuite Distribution page.

The reasoning that recurred across both runs was not that Shopify is incapable of anything. It was simpler: stay on Infor's documented stack to minimize custom integration risk. Both runs were also careful to label their pricing conclusions as inference rather than something Infor states.

That argument rests on an assumption worth examining, which is that the documented path and the only supported path are the same thing.

They are not, and SX.e is the clearest case of it in this whole product line. Infor publicly documents the Service Interface REST API Service, documents how its authentication is configured, and documents named ION API endpoints specifically for external pricing updates, including the exact validation applied and the error categories returned. That is a documented, supported, public integration surface. Anything that can make an authenticated REST call can use it.

So the honest version of the risk argument is not "Shopify is risky". It is "integration work is risky when nobody has read the documentation". Which is true, and is a question about your partner rather than your platform.

Infor documents the Service Interface REST API Service for CloudSuite Distribution and SX.e. Endpoint authentication is configured in SA Application Integration Endpoint, and on a CloudSuite tenant that endpoint is normally set up by Infor Cloud Service rather than by you.

Authentication depends on where you run. The endpoint setup takes an application ID, with sxapi given as Infor's own example, and a type of either Bypass OAuth Security or OAuth 2.0, with grant types covering Authorization Code, Client Credentials, Password and Refresh Token. On-premises SX.e connecting to the Infor OS Authorization Service uses the Password grant, with the user field taking the saak value from your downloaded ION API Authorization credentials. For inbound calls the URL field is left blank, because the SX REST API service authenticates against the URL sent with the call.

None of that is exotic. It does mean the first real question in any project is which deployment you are on, because the answer changes the authentication design and it is the single most common thing to get stuck on.

Pricing has its own endpoints and its own rules, and this is the part no competing page mentions. External pricing updates are supported through ION API using sxapiPDPricingAllMnt for pricing records and sxapiPDPriceSheetMnt for price sheets. Infor applies the Import Excel logic from PD Mass Maintenance Entry to what arrives, so the same validation that governs a spreadsheet import governs the API. Failures come back in three categories: Fatal where the API call data is invalid or missing, PDEM where the pricing data is invalid or missing, and Duplicate where the Allow Multiple Prices business rule forbids a second identical record. They also appear in Electronic Transaction Control Center Entry, which is somewhere your team already works.

One more piece of Infor's own guidance shapes the design more than anything else here: add pricing records rather than modify existing ones, so history is preserved, and avoid blank end dates. An integration that treats a price as a field to overwrite is working against the system it is writing into. This is the detail that separates a build by someone who read the documentation from one by someone who did not.

What Infor does not publish is a rate limit. There is no documented request ceiling or throttling threshold for these endpoints that we could verify, so the sync is designed to your volumes, instrumented, and measured.

Everything else on an SX.e build is tractable. Pricing is where the time goes, and both prompt runs independently named it the single biggest design item.

Infor's own documentation describes matrix pricing by numbered price types rather than by the informal names the trade uses. Type 1 resolves on customer and product. Type 4 resolves on customer price type and product price type, which is the broader grouping most distributors actually run at volume. Quantity breaks operate within those. You will hear all of this called buy matrix and sell matrix pricing by people who work in SX.e every day, and that vocabulary is perfectly real, but it is practitioner language rather than Infor's documented terms, and knowing the difference tells you who has read what.

The effect is the same either way. One item resolves to many different net prices depending on who is asking, how much they are buying, and which type the agreement sits at. That logic is the commercial structure of your business.

The failure mode is always the same too. A price file is exported into Shopify, the matrix moves on, and a buyer is quoted one number and invoiced another. They call inside sales to check the next order, and the self-service channel you built to reduce cost starts generating phone calls.

So the resolution stays in SX.e and the storefront asks for the net price for the account that is logged in. Shopify catalogs still earn their place controlling which products an account may see, which is what they are actually good at.

A contractor cares about what is on the shelf at the branch they can reach today. National stock is a number that helps nobody, and branch-level availability is also what makes counter pickup a real fulfillment option rather than a note on the order.

Multi-branch availability is its own workstream, which both prompt runs also flagged. The rules are business decisions: which branches a given customer sees, whether the number shown is on hand or available to sell after commitments, and what happens when the nearest branch is short but another has it.

The other thing both runs raised independently is worth repeating because it catches distributors out. Your SX.e item master is not sufficient to build a storefront on. It holds what the business needs to transact, not what a buyer needs to choose. Descriptions, attributes, images, documents and the structured data that search and filtering depend on generally have to come from a PIM or an industry data source alongside the ERP. Budget for it, because a storefront built on item master records alone looks exactly like what it is.

SX.e customers become Shopify companies, with their ship-to addresses as company locations and their contacts as buyer logins, including the parent account and buying group structure, so each buyer signs into the account they are authorized to buy for.

Items become products with the attributes and units of measure the catalog needs, enriched from wherever your product content actually lives.

Availability comes by branch, with the visibility rules agreed rather than inherited.

A Shopify order becomes an SX.e order through the REST service with branch routing and account data attached, so fulfillment starts without waiting for a sync window. Credit limits and payment terms are applied at checkout from the customer record rather than caught by accounts receivable later.

Pricing updates written back go through the documented ION API endpoints, so PD validation applies and failures land in Electronic Transaction Control Center Entry where somebody will see them.

Uncap Connect keeps pricing, inventory, customer data and orders current in both directions, built for B2B so customer-specific pricing, credit terms and tax behave the way they do in your business.

SX.e is unusually good here, because Infor has already defined the error taxonomy for pricing writes, and the three categories tell you what to do.

Fatal means the call itself was malformed, which is a code problem and should never reach production more than once. PDEM means the pricing data was invalid, which is a data problem and belongs with whoever maintains pricing. Duplicate means a business rule forbade the record, which is usually correct behavior rather than an error at all. Treating all three the same way is how integrations end up with a log nobody reads.

Orders have their own failures: an account over its credit limit, a product blocked at that branch, a timeout. Transient failures retry on a backoff. Permanent failures hold with the payload and the exact SX.e error preserved, somewhere your team already looks, and replay without asking the customer to order again. The buyer's Shopify order stays visible to them throughout.

Live matrix pricing resolution from SX.e for the logged-in account, respecting price types and quantity breaks, with catalogs used for entitlement rather than as a price copy.

Branch availability with the visibility and allocation rules written down, plus counter pickup as a real fulfillment option.

Company accounts, company locations and buyer logins mapped from the SX.e customer hierarchy including buying groups.

Catalog enrichment from a PIM or your industry data source, because the item master alone will not carry a storefront.

Order creation through the Service Interface REST API Service with deployment-appropriate authentication rather than a shared credential.

Pricing writes through the documented ION API endpoints, respecting the add-rather-than-overwrite guidance, with the three error categories handled as three different things.

One Shopify store carrying B2B and DTC on one catalog and one availability position.

Industrial Supply and MRO, where catalogs run past a hundred thousand items and procurement buys through its own systems.

Electrical Distribution, where matrix pricing and special price agreements are the commercial structure of the business.

Plumbing, HVAC and Mechanical, where a contractor knows the machine and needs the part that fits it.

SX.e is one of several Infor products we connect to Shopify. The Infor integration overview covers M3, CloudSuite Industrial, LN and VISUAL.

Bring your deployment model, whether CloudSuite Distribution or on-premises SX.e, one account's matrix pricing with its price types, and an honest view of what your item master actually contains. In an SX.e project the pricing structure is the project and the product content is the surprise.

Book a strategy session, or start with a Blueprint, the paid discovery engagement that maps the integration surface, the pricing model and the phased plan before development begins.