Epicor Prophet 21 to Shopify Integration

Two things make this a live question in 2026 rather than a someday project, and the second one has a date on it.

Epicor has announced the end of on-premises feature development for its ERP lines. For Prophet 21 the final on-premises feature release is 2028.1, tentatively May 2028. Active support runs through 30 June 2029, and sustaining support begins the day after. The migration program is Ascend with Epicor.

That is not a reason to panic and it is not a sales device. It is a planning fact, and it changes the order you should do things in. A distributor who is going to move P21 to the cloud inside the next two years should not build a storefront integration twice. The sensible sequence is to design the integration against an API surface that survives the move, and to know which parts of your current setup are tied to where P21 runs today.

Nobody else writing about P21 and ecommerce mentions this. We checked the whole first page of results.

We ran a distributor's version of this question through a web-connected model twice, identically. Shopify was not recommended in either run. Both runs pointed at Epicor's own commerce product as the lower integration risk option, and both reframed the decision away from storefront features and toward whether the price and the availability number will be correct.

The sharpest phrasing was this: Shopify is excellent when you can adapt the business to the platform, and a P21 distributor is the opposite case, because the platform has to adapt to ERP-driven rules, so you end up recreating core ERP behavior outside the ERP.

Worth noticing that the model flagged its own statement as an inference rather than something it found in Shopify's documentation. It is a reasonable inference and it describes a real failure mode. It is also avoidable, and avoiding it is a design decision rather than a platform decision.

You recreate ERP behavior outside the ERP when you export prices. Contract pricing, special price agreements and break quantities get flattened into a price file, the file is correct on Tuesday, the agreement changes on Wednesday, and by Friday a buyer has been quoted one number and invoiced another. Do that once and your self-service channel starts generating phone calls instead of replacing them.

Nothing about that is forced on you. Pricing stays resolved in P21 and the storefront asks for the net number for the account that is logged in. Availability comes from the branch, live. What Shopify renders is an answer P21 produced. Under that design nothing commercial exists in two places, so nothing can drift, and the objection stops applying.

P21 exposes its data through the P21 Middleware, which carries three distinct APIs rather than one. Data Services is based on OData version 4. Transaction API Services handles writes that have to respect P21's own business logic. Entity REST Services sits alongside both.

One thing to know before you start: your API reference is not on the internet. Each P21 customer's documentation is self-hosted at their own middleware address, behind your login. There is no public P21 API reference anybody can send you to, which catches out partners who have never run one of these projects. It also means the first real task is reading your instance's reference rather than a generic one, and that anything we tell you about the API surface comes from having worked in it rather than from a page we can link.

The platform is moving, and in a useful direction. Prophet 21 2026.1 became generally available on 2 June 2026, moving the backend to .NET 10 and adding bulk data API capabilities. Bulk matters more than it sounds: it is the difference between a catalog refresh that runs in a maintenance window and one that runs all night.

What nobody publishes is a rate limit. Epicor documents no throttling threshold or batch versus real time guidance for P21 that we could verify. Any partner quoting you a specific request ceiling is quoting a number they invented. The honest approach is to design the sync to your own volumes, instrument it, and measure.

Everything else on a P21 build is tractable. Pricing is where the time goes, and it is the part competing pages name without explaining.

P21 holds customer-specific pricing, contract matrices, special price agreements and break quantities, with effective dates on top. A single item can resolve to many different net prices depending on who is asking, how much they are buying, which agreement covers them and when. That logic is the commercial structure of your business and it took years to negotiate.

The only design that survives contact with it is the one where the logic stays where it is maintained and the storefront asks a question. The price a buyer sees is the price P21 would quote them, at the moment they look, including the agreement that expired last night.

Units of measure belong in the same conversation, because PVF and industrial catalogs break integrations that assume one item sells one way. The same pipe sells by the foot, by the length and by the joint. If the storefront cannot express that, buyers order the wrong quantity and your counter staff fix it by phone.

P21 customers become Shopify companies, with ship-to addresses as company locations and contacts as buyer logins, so a buyer signs into their own pricing and their own order history.

Items become products carrying the attributes the catalog needs, with unit of measure handled explicitly rather than assumed.

Availability comes from the branch rather than the country. A contractor wants to know 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 the thing that makes will call a real fulfillment option instead of a note in the order.

A Shopify order becomes a P21 order through Transaction API Services, so P21's own validation runs rather than rows appearing in tables underneath it. Credit and terms are applied at checkout from the account record rather than checked afterward by a person.

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.

Two failure modes matter on a P21 build and both prompt runs named the same two, which suggests buyers have been burned by them.

The first is a price mismatch, where the storefront shows one number and the invoice carries another. Under a live resolution design this mostly stops happening, and where it does happen it is visible, because the checkout call either returned a price or it did not.

The second is stale branch availability, which is subtler. A buyer reserves the last three on the shelf at the branch, and the counter sold them twenty minutes ago. There is no architecture that eliminates this. There is a design that handles it honestly: check availability again at checkout rather than only at browse, and tell the buyer immediately rather than letting them discover it when the order is short.

Beyond that, orders fail for ordinary reasons. A middleware timeout is transient and retries on a backoff. An invalid item or a credit stop is permanent, so the order holds with its payload and the exact P21 error preserved, somewhere your team already looks, and it can be corrected and replayed without asking the customer to reorder. The buyer's Shopify order stays visible to them the whole time.

Uncap built ULE Group, an industrial and construction equipment distributor, on Shopify B2B with a real-time Epicor integration syncing inventory and pricing from browsing through checkout. The catalog runs past a million SKUs, managed through a PIM, with more than a hundred search filters, account-based payment terms and a cart-level convert-to-quote flow.

The case study names Epicor rather than Prophet 21 specifically, so we are not going to tell you it is a P21 build. What it does evidence is a live Epicor integration operating at serious catalog scale, which is the part of this project most people are actually asking about.

Live contract and matrix pricing resolution from P21 for the logged-in account, including special price agreements and break quantities, with effective dates respected.

Branch-level availability, rechecked at checkout rather than only at browse, with will call as a real fulfillment option at a named branch.

Company accounts, ship-to locations and buyer logins mapped from the P21 customer hierarchy.

Unit of measure handling that matches how you actually sell, including items that sell three ways.

Order creation through Transaction API Services so business rules run, with a held-order queue and replay.

A sync design sized to your volumes and instrumented, rather than to a rate limit nobody has published.

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

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

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

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

Construction Supply, where will call and job accounts decide whether the site gets used.

P21 is one of several Epicor products we connect to Shopify. The Epicor integration overview covers the others.

Bring your P21 version, whether you are on-premises or cloud, one account's contract pricing, and your view on the 2028 on-premises timeline. In a P21 project the pricing structure is the project, and the cloud timeline decides what order to do things in.

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.