--- title: "Sage 100 to Shopify Integration" url: https://www.uncap.com/integration/sage-100 author: "Denis Dyli" published: 2026-09-25 updated: 2026-09-25 summary: "Sage 100 has been running distribution businesses for decades and it is good at it. What it does not have is a modern web API, and almost nobody selling you an integration will say so plainly. Anything described to you as a \"real-time Sage 100 integration\" involves a Windows-side component running near your Sage server, holding a session and doing the work. Price schedules map naturally onto Shopify B2B catalogs, which is the correct home for account-level pricing on the storefront side." --- # Sage 100 to Shopify Integration > Sage 100 has been running distribution businesses for decades and it is good at it. What it does not have is a modern web API, and almost nobody selling you an integration will say so plainly. Anything described to you as a "real-time Sage 100 integration" involves a Windows-side component running near your Sage server, holding a session and doing the work. Price schedules map naturally onto Shopify B2B catalogs, which is the correct home for account-level pricing on the storefront side. What it does not have is a modern web API, and almost nobody selling you an integration will say so plainly. So we will. ## What Sage 100 actually exposes There are two documented integration surfaces and a third path that is not really an API at all. The Business Objects Interface is the main one, and it is built on the Component Object Model. COM is a Windows technology for programs talking to other programs on the same machine. It is in-process, it is session-bound, and it is not something a cloud service can call over the internet. That is not a criticism of Sage 100, it is just what COM is. The practical consequence is the single most important fact on this page. Anything described to you as a "real-time Sage 100 integration" involves a Windows-side component running near your Sage server, holding a session and doing the work. There is no other way. That component is part of the build, it needs somewhere to live, and it needs somebody to operate it. This is why every vendor in this market sells a connector rather than an app, whether or not they explain the reason. The second surface is eBusiness Web Services, which is SOAP over IIS. It is genuinely a web service, and its scope is narrow: sales orders, customers and customer contacts. Inventory is not in it. So it cannot be the whole answer for a storefront, because availability is exactly the thing a buyer needs. Third, there is Visual Integrator and ODBC, Sage's documented import and export route. Good for bulk and batch work, wrong for anything a buyer is waiting on. A note on something you may encounter. At least one page competing for this term publishes a table of Sage 100 REST endpoints with paths like `/AR/Customer` and `/SO/SalesOrder`. **There is no documented Sage 100 REST API.** Those endpoints do not exist. We mention it because it is the kind of thing that looks authoritative in a sales meeting, and because knowing the real mechanism is how you tell a scoped project from a guessed one. Editions matter too. Sage 100 Premium runs on Microsoft SQL Server, which has to be installed before Sage 100 itself. Standard and Advanced use Sage's file-based data store instead. Which one you run changes what direct-read options exist for reporting and availability, so it belongs in the first conversation. ## The objection worth answering We ran a Sage 100 distributor's platform question through a web-connected model twice, identically. Shopify came third in both runs, and the reason recurred exactly: Shopify's own help documentation warns that some App Store integrations are not fully compatible with B2B companies and catalogs. That is a real warning from a real source and it deserves a straight answer rather than a dismissal. Notice what it is actually about. It is not a statement that Shopify's B2B capabilities are weak. It is a statement about apps: an integration that does not properly implement Shopify's B2B APIs will not map your data into companies, company locations and catalogs correctly, and your B2B behavior will be wrong even though the platform supports it. Which means the thing to interrogate is not the platform, it is the integration layer. The questions are specific. Does the integration create real Shopify Companies from your Sage customers, or generic customer records with tags. Do your ship-to addresses become Company Locations with their own terms, or one address per account. Do your Sage price schedules become B2B Catalogs assigned to the right accounts. If the answer to any of those is no, the warning applies and the objection is correct. [Uncap Connect](https://www.uncap.com/products/connect) is built against Shopify's B2B APIs and runs embedded inside Shopify rather than sitting outside it as a general purpose sync tool. That is the distinction the warning is pointing at. ## How a price is decided Sage 100 resolves a price through six levels, and the terminology is Sage's own rather than generic distribution vocabulary, which is worth using correctly. Promotional pricing takes precedence first. Below it comes the customer price schedule. Then item pricing by customer price level, then the price level held in Price Code Maintenance, then the standard price code, and finally the standard price on the item itself. The number a customer pays is whatever survives that sequence. None of that lives on the product record, which is why exporting prices into Shopify produces a copy rather than an integration. For a distributor running price schedules across a few hundred accounts, that copy is wrong somewhere within a week and nobody notices until a customer does. Price schedules map naturally onto Shopify B2B catalogs, which is the correct home for account-level pricing on the storefront side. Where a price is computed rather than listed, the resolution stays in Sage 100 and the storefront asks. ## "Real-time" is a claim, not a feature Both prompt runs independently warned that real-time inventory on Sage 100 is often not real time, and gave the buyer a list of questions to put to vendors. It is a fair warning, and given what COM is, it is also predictable. Here is what the phrase has to mean before it means anything. What is the polling interval, and is it the same for every item or weighted toward fast movers. Is the quantity on hand, or available to sell after allocations and committed quantities. Is it per warehouse, and does the storefront show the warehouse that will actually ship. What happens to a backordered line. And is availability checked again at checkout, or only when the page was built. A vendor who answers those five questions with numbers has an architecture. A vendor who answers with the word "real-time" has a slide. ## Where the two systems line up Sage 100 customers become Shopify Companies. Ship-to addresses become Company Locations carrying their own terms. Contacts become buyer logins under the right company, so each person signs into the account they are authorized to buy for. Items become products with their attributes and units of measure intact. Distributors selling by each, case and pallet are asking Shopify to represent one Sage item three ways, and it has to be expressible or buyers order the wrong quantity. Price schedules become B2B catalogs for entitlement and listed pricing, with computed prices resolved from Sage at the moment they are needed. A Shopify order becomes a Sage 100 sales order with line detail, the customer reference and terms mapped, written through the Business Objects Interface so Sage's own validation applies. Shipment and invoice events return to the buyer's account. ## What happens when an order fails The Windows-side component is the thing to think about here, because it is a moving part your architecture depends on and most pages pretend it does not exist. If it stops, orders stop reaching Sage. That is survivable if the orders queue and are replayed, and it is a bad afternoon if they are lost. So orders hold with their payload and the exact Sage error preserved, somewhere your team already looks, and they replay without asking the customer to order again. Session failures in the Business Objects Interface retry, because a dropped COM session is not a data problem. Genuine rejections, such as a blocked item or a customer over their credit limit, stop and wait for a person. The buyer's Shopify order stays visible to them throughout. From their side the order exists, and silence is worse than an exception. ## What we build The Windows-side component that talks to the Business Objects Interface, sized and operated as part of the engagement rather than left as an implied detail. Price resolution respecting Sage's six-level hierarchy, with price schedules mapped to Shopify B2B catalogs and computed prices resolved from Sage. Companies, Company Locations and buyer logins created through Shopify's B2B APIs, which is the specific thing Shopify's own documentation warns that generic integrations get wrong. Inventory sync with a stated polling design, on hand versus available to sell settled explicitly, per warehouse, and rechecked at checkout. Order creation through the Business Objects Interface with a held-order queue and replay. One Shopify store carrying B2B and DTC on one catalog and one inventory position. ## Industries that run Sage 100 [Industrial Supply and MRO](https://www.uncap.com/industry/industrial-supply-mro), where catalog scale and account pricing decide whether a storefront gets used. [Packaging and Shipping Supplies](https://www.uncap.com/industry/packaging-shipping-supplies), where each, case and pallet pricing has to resolve correctly for every account. [Home Goods](https://www.uncap.com/industry/home-goods), where retail accounts and a consumer channel run from one catalog. Sage 100 is one of several Sage products we connect to Shopify. The [Sage integration overview](https://www.uncap.com/integration/sage) covers the others. ## Ready to talk Bring your edition, whether Premium on SQL Server or Standard or Advanced, one account's price schedule, and where a Windows-side component could live on your network. 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 100 have a REST API? No. Sage documents the Business Objects Interface, which is built on the Component Object Model, and eBusiness Web Services, which is SOAP and covers sales orders, customers and customer contacts only. Visual Integrator and ODBC handle bulk import and export. If you have been shown a table of Sage 100 REST endpoints, they are not real, and that is worth knowing before you evaluate the rest of that proposal. ### What does COM mean for my integration in practice? It means something has to run on Windows near your Sage 100 server, holding a session and doing the work, because COM is in-process and cannot be called across the internet. That component is part of the build and part of the ongoing operation. It is also why every vendor in this market sells a connector rather than a cloud app. ### Shopify's documentation warns that some integrations do not map B2B data correctly. Is that a reason to avoid Shopify? It is a reason to interrogate the integration rather than the platform. The warning is about apps that do not properly implement Shopify's B2B APIs, which then fail to create real Companies, Company Locations and Catalogs from your ERP data. Ask whether your Sage customers become actual Shopify Companies, whether ship-to addresses become Company Locations with their own terms, and whether price schedules become assigned B2B Catalogs. If the answers are no, the warning applies. ### Can Sage 100 pricing work on a Shopify storefront? Yes, and it needs the six-level hierarchy respected rather than flattened. Sage resolves a price through promotional pricing, then the customer price schedule, then item pricing by customer price level, then the price level in Price Code Maintenance, then the standard price code, then the item's standard price. Price schedules map well onto Shopify B2B catalogs. Prices that are computed rather than listed are resolved from Sage when they are needed. ### Is real-time inventory actually possible? It depends entirely on what someone means by the phrase, which is why it is worth pinning down. Ask for the polling interval, whether the figure is quantity on hand or available to sell after allocations, whether it is per warehouse, how backorders display, and whether availability is rechecked at checkout or only when the page was built. Answers with numbers indicate an architecture. ### Does our Sage 100 edition matter? Yes. Premium runs on Microsoft SQL Server, which must be installed before Sage 100. Standard and Advanced use Sage's file-based data store. The difference affects what direct-read options are available for reporting and availability, so it belongs in the first conversation rather than the third. ### What happens if the integration component goes down? Orders queue and replay rather than disappearing. Dropped sessions retry, since that is a connectivity problem rather than a data problem. Genuine rejections such as a blocked item or a credit stop are held with the Sage error attached for a person to resolve. The buyer keeps seeing their order in Shopify the entire time. ### How long does a Sage 100 Shopify integration take? Pricing configuration and data quality drive it more than catalog size, and the Windows-side component adds an infrastructure conversation most cloud ERP projects skip. The Blueprint engagement settles the scope before anyone commits to a date.