Think of an online store like a shop. The website is the window, and checkout is the counter. But a shop needs a back office too. Someone has to know the prices and stock. Someone has to keep the product details. And someone has to pack and ship the orders.
That’s what the ERP, PIM, and OMS do for a Salesforce Commerce Cloud (SFCC) store. The hard part is getting them to talk to each other. In this article, I’ll show how SFCC connects to them, where things go wrong, and what to plan for.
Let’s start with the ERP, the back office that owns prices and stock levels. Apart from this, it also takes care of the monetary side.
The PIM holds product content for every item. This includes all the basic information such as the name and description, plus the images and other details.
The OMS comes into play once an order is placed. Then it handles packing and shipping. And later on, it also deals with returns or refunds.
SFCC needs to exchange data with all three.
How SFCC connects to other systems
APIs carry most of this traffic, and SFCC’s current API set, which is called SCAPI, is split into two groups.
Shopper APIs power the storefront, and their work is mostly just to read data. However, baskets and orders are the exceptions. This is because shoppers should be able to add items and buy them.
That was about shopper APIs. Admin APIs behave a little differently and are designed for back-office systems. For this reason, they can write as well as read. Products, their prices, and stock levels can all be updated through them.
Some older stores may still be on OCAPI. Salesforce deprecated it in April 2026, so if that’s you, start planning the move now. It’ll keep running for another two years and still receive security fixes, but it will not get new features. A good E-commerce development company such as Vilmate can help you list which OCAPI calls you use today and map each one to SCAPI.
Developers can also add their own code. For instance, a developer can add a hook that runs when a particular event happens, like a shopper’s request reaching an API. If none of the standard APIs fit, a Custom API lets you build a new endpoint from scratch.
This does not mean that everything has to go through an API, either. For instance, large data sets often move as files. A PIM can send a big product file for SFCC to import at a scheduled time. Additionally, orders can be exported the same way. To understand deeply how SFCC projects are usually set up, I advise reading this technical overview.
So the catch is, which route you pick should depend on how often the data changes. Product details don’t change much, so scheduled file imports are a good fit. On the other hand, stock changes constantly and is better handled through API calls.
Where it gets hard
Slow back-end systems
Let’s assume a general scenario where a hook calls the ERP while a shopper is loading a page. The shopper has to wait for as long as the ERP takes to respond, up to the default hook timeout of 10 seconds for Shopper API hooks.
There’s also a circuit breaker. When hook calls fail on 50 of the last 100 requests, the platform starts rejecting requests. This is crucial, as in practice, one slow back-office system can bring down the storefront features that depend on that hook, and nobody wants that to happen.
So it’s best to keep the ERP out of the page load. Instead, have it send price and stock updates to SFCC in advance. This ensures the data is ready when shoppers need it.
Rate limits
Some services only accept a certain number of calls in a short period. At the time of writing, Omnichannel Inventory’s stock update service allows 100 requests every 10 seconds. Starting a stock import is far stricter, at 2 every 10 seconds. If you send stock updates one by one, you’ll reach those limits fast, at which point the service returns a 429 error.
If the store experiences high traffic, the platform may limit incoming requests. However, checkout is exempt from this, ensuring customers can still place their orders.
Your integration should expect 429 and 503 errors, which means waiting and retrying. Retrying has a side effect, though: the same message can arrive more than once. It also needs to be idempotent, which just means a duplicate does no harm.
Size limits
Requests are capped at 5 MB and responses at 10 MB. Anything larger has to be split into smaller batches before it’s sent.
File imports have a separate catch. If you load a bad file, you can’t undo it. So I advise keeping a copy of the last good file before every import.
Order tracking after checkout
Taking orders is something SFCC does very well. After that, the order is in the OMS’s hands, and SFCC doesn’t know what happens to it. Because of this, by default, when customers check their order details, the status they see is the same as the order’s status at the time of purchase. So there are no live shipping updates.
You can display live updates using Salesforce Order Management. Moreover, you can write your own code that fetches the latest order status.
A good setup requires two key decisions that can affect the overall experience. First, add middleware between SFCC and the OMS to queue failed messages and retry them automatically. The second step is to decide early which system will handle order status lookups. These calls happen every time a customer views an order, so slow responses can affect site performance.
Before you build
In summary, I would say taking time to plan everything can make a big difference. The ideal way I recommend is to spend a day or two sorting out these details before you begin development. Once the store is live, dealing with these limitations becomes much more difficult. In the longer run, it will save you time and effort, so you should consider a proper plan.
