---
title: "Sage 300 to Shopify Integration"
url: https://www.uncap.com/integration/sage-300
author: "Denis Dyli"
published: 2026-09-27
updated: 2026-09-27
summary: "Sage 300, still called Accpac by plenty of the people running it, is built for multi-entity and multi-currency operations. Sage 300 exposes the Sage 300 Web API, a genuine HTTP interface following OData over JSON. It can be called over HTTPS from somewhere else. No COM host required."
---

# Sage 300 to Shopify Integration

> Sage 300, still called Accpac by plenty of the people running it, is built for multi-entity and multi-currency operations. Sage 300 exposes the Sage 300 Web API, a genuine HTTP interface following OData over JSON. It can be called over HTTPS from somewhere else. No COM host required.

It also has something its sibling does not, and the difference decides how your integration is shaped.

## Sage 300 has a real web API. Sage 100 does not.

This is the most useful thing to know before you scope anything, and nobody competing for this term says it.

Sage 100's Business Objects Interface is built on COM, which is in-process and Windows-bound, so every real-time Sage 100 integration needs a component running on a Windows machine near the Sage server. There is no way around it.

Sage 300 exposes the **Sage 300 Web API**, a genuine HTTP interface following OData over JSON. It can be called over HTTPS from somewhere else. No COM host required.

The base URL follows a specific shape and it is worth reading closely, because one segment of it does something important:

`{protocol}://{host}/Sage300WebApi/v1.0/-/{company}/{module}/{resource}`

That `{company}` segment is your Sage 300 database ID. Multi-entity routing is not a clever piece of middleware. It is a segment in the URL. An order for the Canadian entity and an order for the US entity go to different paths, and the integration's job is to decide which, from the account and the storefront context.

Authentication is HTTP Basic over TLS. Not OAuth. We mention it because proposals sometimes assume OAuth and then discover otherwise; if someone has quoted you an OAuth flow for Sage 300, ask which documentation they read.

The API covers the modules you would expect, including AR, IC and OE, with resources such as ARCustomers, ARShipToLocations, ARTerms, ICItems, ICLocations, ICPriceListCodes, ICUnitsOfMeasure, OEOrders and OEInvoices. It is actively maintained; the Sage 300 2026 release notes carry a Web API section adding new endpoints.

## Where the Web API stops, which matters more than where it starts

Here is the part that turns a clean story into an accurate one.

The Web API is a thin OData surface over Sage 300's Views, which are the business objects that hold the validation and posting rules. A resource exists only where a View has been surfaced. So coverage is uneven, and the gaps are not random, they are simply wherever Sage has not yet published one.

Two gaps matter for commerce.

**There appears to be no OE Shipment endpoint.** A request for one has been open in Sage's own community for around five years, with a user noting in 2025 that Sage 300 2025 still did not have it. Sage has not responded in that thread, so treat this as community-sourced rather than an official statement, and as something to verify against your own version. If it holds, shipment write-back needs another route, and any vendor promising shipment sync should be asked which one they use.

**Customer contract pricing has no documented Web API resource.** I/C Contract Pricing is a real and documented Sage 300 feature, but the endpoint reference we could reach covers only the purchasing-side contract costs. So contract pricing is reached through the View or .NET layer, or resolved at runtime, rather than through a REST call. Anyone showing you a REST endpoint for customer contract pricing should be asked to name it.

None of this is a reason to avoid Sage 300. It is the difference between a scoped project and a guessed one.

## The other two ways in, and when they apply

The **.NET API** is current and supported, delivered through ACCPAC.Advantage.dll. It is Windows-side and in-process, so it is not a network API, but it reaches everything the Views expose rather than only what has been surfaced as a REST resource. Where the Web API has a gap, this is usually the answer.

The **COM API** is the original interface and should be treated as legacy for new integration work. Sage's own engineering commentary makes the point that if you are writing an integration to something like a web server, the COM object model is not what you want.

All three sit on the same Views underneath, which is why they agree with each other and why the Views are the thing to understand.

## How a price gets decided

Sage 300 holds price list codes, assigned per A/R customer, and the Premium edition adds pricing by unit of measure, by weight and by quantity. Price list codes are reachable through the Web API with full create, read, update and delete.

Contract pricing, as above, is not a documented REST resource. So the honest design is that listed pricing can be synced into Shopify B2B catalogs, and anything computed, including contract pricing, is resolved from Sage 300 at the moment it is needed through a route that can reach it.

A/R ship-to locations deserve a specific mention because the mapping is unusually clean. Ship-to is a first-class Sage 300 entity with its own record, and it maps directly onto Shopify B2B company locations, each able to carry its own terms. Distributors used to fighting their ERP's address model find this one straightforward.

## Where the two systems line up

Sage 300 A/R customers become Shopify companies. Ship-to locations become company locations with their own terms. Contacts become buyer logins under the right company.

Items become products with the units of measure the catalog needs, drawn from ICItems and ICUnitsOfMeasure.

Inventory comes from IC by location, so a buyer sees the warehouse that will actually ship.

Price list codes map into Shopify B2B catalogs; computed pricing resolves from Sage.

A Shopify order becomes a Sage 300 OE order in the correct company, routed by that `{company}` URL segment, with the customer reference 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

The Sage 300 specifics are the entity one and the endpoint one.

If an order is routed to the wrong company, it does not fail loudly. It lands, correctly formed, in the wrong set of books, and somebody in finance finds it later. So entity resolution is validated before submission rather than trusted, and mis-routing is treated as a blocking error rather than a warning.

Where a needed operation has no Web API resource, the integration has a documented fallback path rather than a silent gap. Knowing which operations those are is discovery work, not something to find out in testing.

Beyond that the pattern is the usual one. Transient failures retry on a backoff. Permanent failures hold with the payload and the exact Sage error preserved, somewhere your team already looks, and replay without asking the customer to reorder. The buyer's Shopify order stays visible to them throughout.

## Industries that run Sage 300

[Construction Supply](https://www.uncap.com/industry/construction-supply), where will call and job accounts decide whether the site gets used.

[Building Materials](https://www.uncap.com/industry/building-materials), where products sell by area and length, a waste factor has to be added before a quantity is correct, and lead times decide whether a quote is usable.

[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.

Sage 300 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 X3.

## Ready to talk

Bring your Sage 300 version and edition, how many companies are in scope, and one account's price list setup. If you use contract pricing, say so early, because that is the part with no documented REST route.

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 300 have a REST API?

It has the Sage 300 Web API, which is an HTTP interface following OData over JSON. It is reachable over HTTPS from outside the network, which is a genuine difference from Sage 100, whose Business Objects Interface is COM-based and needs a Windows component running near the server.

### How does authentication work?

HTTP Basic over TLS. There is no OAuth flow documented for the Sage 300 Web API. It is worth confirming with any partner, because proposals sometimes assume OAuth and have to be reworked.

### How does multi-entity order routing work?

Through the URL. The Web API path carries a company segment holding your Sage 300 database ID, so an order for one entity and an order for another go to different paths. The integration's job is deciding which company an order belongs to from the account and storefront context, and validating that decision before submitting.

### Does the Web API cover everything?

No, and this is the most important limitation to scope around. It is a thin OData layer over Sage 300's Views, and a resource exists only where a View has been surfaced. Two gaps matter for commerce: there appears to be no OE Shipment endpoint, which has been an open community request for around five years, and customer contract pricing has no documented Web API resource. Where a gap exists, the .NET API reaches what the Views expose.

### Can Sage 300 contract pricing work on a Shopify storefront?

Yes, but not through a REST endpoint, because none is documented for customer contract pricing. It is reached through the View or .NET layer, or resolved at runtime. Listed pricing from price list codes can map into Shopify B2B catalogs, while computed pricing resolves from Sage when it is needed.

### How do ship-to addresses map?

Cleanly, which is not always the case. A/R ship-to locations are first-class records in Sage 300 and map directly onto Shopify B2B company locations, each carrying its own terms.

### Does our edition matter?

Yes. Premium adds the full inventory control pricing options, including customer item numbers and pricing by weight, quantity or unit of measure. Standard and Advanced have lower company and user ceilings and fewer segments. It affects what the integration can express.

### How long does a Sage 300 Shopify integration take?

Entity count and pricing complexity drive it more than catalog size. A single company with listed pricing is a different project from four companies with contract pricing and an operation that needs shipment write-back. The Blueprint engagement establishes which you have before anyone commits to a date.