--- title: "Sage X3 to Shopify Integration" url: https://www.uncap.com/integration/sage-x3 author: "Denis Dyli" published: 2026-09-27 updated: 2026-09-27 summary: "Sage X3 runs upper mid-market process manufacturers and distributors: specialty chemicals, food and beverage, pharmaceuticals, nutraceuticals, industrial equipment, cosmetics. Selling that online is mostly a data problem rather than a storefront problem, and there is one piece of X3 infrastructure that decides whether the integration performs. Sage X3 exposes web services in two distinct families, and conflating them is the most common scoping error." --- # Sage X3 to Shopify Integration > Sage X3 runs upper mid-market process manufacturers and distributors: specialty chemicals, food and beverage, pharmaceuticals, nutraceuticals, industrial equipment, cosmetics. Selling that online is mostly a data problem rather than a storefront problem, and there is one piece of X3 infrastructure that decides whether the integration performs. Sage X3 exposes web services in two distinct families, and conflating them is the most common scoping error. Selling that online is mostly a data problem rather than a storefront problem, and there is one piece of X3 infrastructure that decides whether the integration performs. Almost nobody writing about X3 and ecommerce mentions it. ## Two API families, and which one you get depends on your version Sage X3 exposes web services in two distinct families, and conflating them is the most common scoping error. **SOAP web services** are the classic surface. They bind to V6-style objects and sub-programs and have been available since V6. **The Web API** is the REST surface. It binds to V7-style classes and representations, and it is what Sage's own integration guide focuses on. Sage's documentation says plainly that SOAP services have their own separate documentation and that the integration guide concentrates on the Web API instead. Read that carefully, because it is de-emphasis rather than deprecation. We found no Sage statement that SOAP is deprecated or end of life. If your X3 is older, or your functionality is only exposed classically, SOAP is still the route, and a partner who tells you it is dead has not read the page. The Web API URL shape carries two things worth knowing: `http://server:port/api1/x3/$$prod//('key')?representation=REP.$FAC` The `` is your folder, so multi-entity routing is in the URL, the same as it is on Sage 300. And `representation` plus facet are mandatory rather than optional, which is a real difference from a generic REST API and something an integration has to model deliberately. Sitting in front of all of it is **Syracuse**, the node.js web and administration server introduced at V7, which fronts X3 and mediates endpoints and folders. Authentication depends on where you run. On-premises supports basic authentication and client certificates. **Sage X3 Online imposes OAuth 2.0 and Sage documents it as the only method available there.** SOAP additionally accepts bearer tokens. So the authentication design follows your deployment, and that is a first-week question. ## The pool, which is the throughput ceiling nobody mentions This is the detail worth the price of reading this page. X3's classic web services run through pools, which are collections of channels. Sage's documentation makes two statements that matter together. The size of each pool, meaning the number of channels, is no longer controlled by the license. And users can create as many channels as they want, with server sizing considerations needing to be taken into account to size the pool. In plain terms: your throughput ceiling is not licensed, it is configured, and Sage hands the sizing decision to you. There is a sharper edge. The host definition requires a setting for the number of web services children, and it **defaults to zero**, which yields an HTTP 500. An X3 integration that returns server errors from the first call is frequently not a code problem at all. It is an unconfigured pool. Separately, X3 carries license-controlled parameters that throttle **data volume** rather than call rate. These are worth knowing about because they behave differently from a rate limit and will surprise anyone who assumes requests-per-second is the only constraint. What Sage does not publish is a requests-per-second figure or a numeric pool ceiling. So the sync is sized against your pool configuration and measured, rather than designed to a number nobody has published. One thing not to confuse with any of the above: X3 also has an older XTEND REST layer, an AJAX interface over SOAP. It is a different thing from the Web API and it is not where a modern integration should point. ## What process manufacturing does to a storefront Your catalog carries obligations a general distributor's does not. Lot numbers and lot-controlled availability mean the sellable quantity is not one number. It is a number attached to lots with dates, and what you can promise depends on which lots are releasable. Shelf life decides whether a buyer can accept a shipment at all. Some accounts will refuse product below a minimum remaining life, and that rule belongs in the availability logic rather than in a phone call afterward. Certificates of analysis and hazmat documentation have to reach the buyer with the product, and often before they order. Customer-specific formulations mean two accounts ordering what looks like the same item may be ordering different things. Batch schedules and co-packers determine when more exists. None of that is exotic to X3, which is built for it. It is exotic to a generic integration, which is why they fail here. ## Where the two systems line up X3 customers become Shopify companies, with ship-to addresses as company locations and contacts as buyer logins, routed to the correct folder so orders land in the right legal entity. Items become products carrying units of measure and their conversions, with the documentation and attributes a regulated buyer needs. Availability reflects multi-site inventory and lot control rather than a single on-hand figure, with shelf life rules applied where an account requires them. Contract pricing resolves from X3 for the logged-in account rather than being flattened into a storefront price list. A Shopify order becomes an X3 sales order in the correct folder, with the customer reference, requested date and terms attached. [Uncap Connect](https://www.uncap.com/products/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. ## What happens when an order fails Three X3-specific failures are worth designing for. **The pool is saturated.** This looks like intermittent server errors under load and is the most common X3 integration complaint. It is a configuration and sizing problem, not a code problem, and it should be visible in monitoring rather than discovered from customer complaints. **The order is routed to the wrong folder.** Like the Sage 300 company segment, a mis-routed order does not fail loudly. It lands correctly formed in the wrong entity and finance finds it later. Entity resolution gets validated before submission. **No lot satisfies the requirement.** The stock exists and none of it is releasable to that account under its shelf life rule. That is a real business answer and the buyer should get it at checkout with a date, rather than an order that quietly short-ships. Beyond those, transient failures retry on a backoff, permanent failures hold with the payload and the exact X3 error preserved somewhere your team already looks, and they replay without asking the customer to reorder. The buyer's Shopify order stays visible to them throughout. ## Industries that run Sage X3 [Food Service Distribution](https://www.uncap.com/industry/food-service-distribution), where lot traceability and contract pricing run together. [Beverage Distribution](https://www.uncap.com/industry/beverage-distribution), where pack size, route and account pricing decide the order. [Beauty and Cosmetics](https://www.uncap.com/industry/beauty-cosmetics), where formulation, batch and channel separation sit behind a single catalog. Sage X3 is one of several Sage products we connect to Shopify. The [Sage integration overview](https://www.uncap.com/integration/sage) covers Sage 100 and Sage 300. ## Ready to talk Bring your X3 version, whether you are on-premises or on Sage X3 Online, how many folders are in scope, and one account's contract pricing. Ask us to look at your web services pool configuration in the first week, because it is a twenty minute check that prevents a month of confusion. Book a strategy session, or start with a [Blueprint](https://www.uncap.com/blueprint), the paid discovery engagement that maps the integration surface, the pricing model and the phased plan before development begins. ## Frequently asked questions ### Does Sage X3 have a REST API? Yes, the Web API, which binds to V7-style classes and representations. X3 also has classic SOAP web services bound to V6-style objects and sub-programs. Sage's integration guide focuses on the Web API and notes that SOAP has its own separate documentation, but we found no Sage statement that SOAP is deprecated, so which one applies depends on your version and on what your functionality exposes. ### How does authentication work? It depends on deployment. On-premises supports basic authentication and client certificates. Sage X3 Online imposes OAuth 2.0, which Sage documents as the only method available there. SOAP services additionally accept bearer tokens. Establishing your deployment model is therefore a first-week task. ### Why does our X3 integration return server errors under load? Most often because of the web services pool rather than the code. Pools are collections of channels, their size is no longer controlled by the license, and Sage explicitly hands the sizing decision to you based on server capacity. The host definition also requires a number of web services children, which defaults to zero and produces an HTTP 500 until it is set. ### What are the rate limits? Sage publishes no requests-per-second figure or numeric pool ceiling that we could verify. What it does document is license-controlled parameters that throttle data volume rather than call rate, which behave differently from a rate limit. The sync is therefore sized against your pool configuration and measured. ### How does multi-entity routing work? Through the folder, which appears as the endpoint segment in the Web API URL. An order for one legal entity and an order for another go to different paths. Because a mis-routed order lands correctly formed in the wrong entity rather than failing visibly, entity resolution is validated before submission. ### Can the storefront handle lot-controlled availability and shelf life? Yes, and for a process manufacturer it has to. The sellable quantity is attached to lots with dates rather than being a single number, and accounts that require a minimum remaining shelf life need that rule applied in the availability logic rather than caught after shipment. When no lot qualifies, the buyer should be told at checkout with a date. ### What about certificates of analysis and hazmat documentation? They reach the buyer with the product, and often before they order. For regulated categories this is part of the buying decision rather than paperwork that follows it, so the documents belong in the catalog and in the account's order history. ### How long does a Sage X3 Shopify integration take, and what does it cost? 14 to 18 weeks, with investment typically from $65,000 to $130,000 or more depending on scope. Folder count, lot and shelf life complexity, and contract pricing structure are the three things that move it. The Blueprint engagement establishes where you sit before anyone commits.