How Salesforce B2C Commerce Cloud APIs Work Now That OCAPI Is Deprecated 

Salesforce marked the Open Commerce API deprecated in April 2026. B2C Commerce Cloud integrations now run on the Salesforce Commerce API, which uses SLAS for authentication, object level caching for speed, and Custom APIs for extension. OCAPI keeps working with security updates only, so migration is a planning question rather than an emergency. 

What Changed in Salesforce B2C Commerce Cloud APIs Since 2024 

For most of the last decade, integrating with B2C Commerce meant OCAPI. It shipped in 2014, and if you built on the platform, you built there. 

SCAPI arrived in 2020, and for years the honest answer to which one to use was that it depended. OCAPI was more complete. SCAPI was faster and better designed, but had gaps. 

That is now settled. Salesforce’s own migration guidance says three things plainly. All new implementations must use SCAPI exclusively. Teams already on OCAPI must begin planning a migration. And OCAPI stays available for two further years with security updates, but no new features. 

OCAPI Deprecation: What the April 2026 Announcement Actually Means 

Deprecated does not mean switched off. Your OCAPI calls will still return data tomorrow morning. What changed is category: OCAPI has moved from an actively developed product into maintenance. It gets security patches, not features. 

The effect shows up in real work. Omnichannel Inventory, price book administration, CDN zone management, order administration and replication control all have SCAPI Admin services. None has an OCAPI equivalent, and none ever will. The same goes for the AI driven merchandising Salesforce has planned for 2026, built natively on SCAPI. 

So the deadline is not a shutdown date. It is the day a roadmap item you want turns out to need an API you are not on. That day lands differently for every business, which is why this needs planning rather than waiting. 

SCAPI vs OCAPI: The Differences That Affect Integration Cost 

These are not the same product with different URLs. The differences are structural, and they change how an integration behaves under load. 

• Status. OCAPI receives security updates only. SCAPI receives every new endpoint and feature. 

• Where it runs. OCAPI runs on the application tier, competing with Business Manager and storefront logic. SCAPI is decoupled, with a CDN gateway handling authentication and routing first. 

• Caching. OCAPI caches the whole response, so one changed field invalidates all of it. SCAPI caches the object instead. 

• Authentication. OCAPI uses proprietary shopper authentication with no native refresh tokens. SCAPI uses standard OAuth2 through SLAS. 

• Personalization. OCAPI needed a modify response hook, which is server side script you write and maintain. SCAPI has the Shopper Context API and handles it natively. 

• Traffic protection. SCAPI has load shedding on ECOM endpoints and rate limiting on non ECOM endpoints. OCAPI has no equivalent. 

Caching carries the clearest commercial effect. Salesforce reports that web tier caching serves forty to fifty percent of SCAPI requests, so roughly half never reach the application tier. Personalization quietly removes code: with the Shopper Context API you pass shopper attributes such as membership level or region, and the right price comes back. That is a maintenance burden that stops existing rather than moving. 

SLAS Authentication Is Now the Gatekeeper for Every Shopper API Call 

If a migration slips, this is usually where. The Shopper Login and API Access Service, or SLAS, is the required front door for SCAPI. It is also what makes a phased migration possible, because one SLAS token works across both API sets, so you can move a single integration at a time. 

Five behaviors are worth designing around from the start. 

• Guest tokens need channel_id. Required when requesting a guest access token. Enforcement reached all production tenants on 25 March 2025, and a missing value returns a 400 error. Tokens are also tied to one site and cannot be reused across sites. 

• Access tokens last 30 minutes. Refresh handling is the normal path, not an edge case. 

• Refresh lifetimes differ by shopper type. On production, 90 days for registered shoppers and 30 days for guests. Off production, 9 days for everyone. 

• Public client refresh tokens are single use. Each call returns a new one, and reusing the old one fails. Private client refresh tokens can be reused. 

• Password changes revoke earlier tokens. This takes a few minutes and is only switched on by default in production, so the behavior will not appear in sandbox testing unless you enable it. 

The nine day sandbox lifetime against ninety in production is the one that catches teams out. Refresh logic can look healthy through an entire test cycle, then fail three months after go live. 

Choose the client type deliberately rather than inheriting it. The deciding question is whether the application can store a client secret somewhere the shopper cannot reach. Salesforce maps the common cases: single page apps, including a PWA Kit storefront, and mobile apps use a public client, while full stack apps and anything with a backend for frontend layer use a private one. Private clients are more capable, since they can pre authorize guest shoppers and support passwordless login and password reset. PWA Kit 3.5 and above works with either. 

Commerce Apps Replace the Cartridge Model for Packaged Integrations 

The old framing was that you either installed a cartridge or built something custom. Salesforce now describes Commerce Apps as the evolution of the cartridge model into a marketplace ready format. A Commerce App bundles frontend components, backend cartridges, admin configuration and data into one installable package that merchants find in Business Manager and install with a click. 

Cartridges have not gone anywhere. They are now a component inside the package rather than the thing you handle directly, which changes the work in three ways. 

• Installation is a platform managed job. No manual upload, no cartridge path editing, no separate data import. 

• Extension points are domain scoped. An app implements something like sfcc.app.tax.calculate rather than the shared dw.order.calculateTax, which removes the conflicts that appear when two integrations want the same hook. 

• Frontend components are orchestrated for you. If an app includes Storefront Next components, the platform opens a pull request against the merchant’s storefront repository. 

Custom APIs Give SCAPI an Extension Path OCAPI Never Had 

Hooks change the behavior of an endpoint that already exists. When the thing you need has no matching endpoint, a hook is the wrong tool, and under OCAPI that left teams building workarounds. 

SCAPI supports Custom APIs, defined using the OpenAPI specification, which expose your own script logic as proper REST endpoints with authentication built in. Because they sit behind the SCAPI gateway, they inherit its protections: validation at the CDN layer, server side caching, and circuit breaking that stops a runaway process taking the backend down with it. None of this exists in OCAPI, and for teams whose requirements do not map onto standard endpoints it is often the strongest argument for moving. 

Worth being honest about the boundary, though. Orchestration across an ERP, a warehouse system and a marketplace feed is a case when the integration layer needs to live outside the storefront. Building that as Custom APIs produces something that works and then becomes hard to change. 

Planning an OCAPI to SCAPI Migration Without Breaking the Storefront 

Salesforce sets out four steps: audit your OCAPI usage, map each endpoint using the published mapping reference, switch authentication to SLAS, then review the SDKs. That is the right sequence. Three things sit underneath it that the documentation does not spell out. 

Audit against traffic, not against code. An endpoint list tells you what exists; request volume tells you what matters, and the two rarely rank the same way. Most estates contain integrations nobody has called in a year, and rewriting those first is a reliable way to burn a quarter. 

Sequence shopper facing work first, because that is where the caching improvements pay off and it brings SLAS with it, which everything else waits on. Leave the administrative tail until last. 

Treat the hybrid period as a real phase with an owner. Hybrid Auth keeps sessions in sync between legacy SFRA or SiteGenesis pages and a modern storefront so baskets survive the transition, and someone needs to own that while both paths are live. One note on effort: the B2C Commerce CLI now ships over two hundred commands covering work that used to mean clicking through Business Manager, so estimates built on manual configuration are probably too high. 

What Is Still Missing From SCAPI in 2026 

A migration guide claiming full parity is not being straight with you. As of May 2026, Salesforce documents two areas still best handled through OCAPI: system information, meaning low level server status and maintenance indicators, and a set of complex Data API tasks with no Admin SCAPI service yet. Both are committed but undated. 

One more gap to catch during an audit. Data Metrics has no direct replacement and is being superseded by distributed tracking and tracing, planned for the 26.4 release. If your monitoring depends on it, raise that early rather than discovering it during a cutover rehearsal. None of this argues for delay. It argues for sequencing the administrative tail last, and keeping a small OCAPI surface alive on purpose rather than by neglect. 

Where This Leaves Your B2C Commerce Integration Roadmap 

What used to be a question of preference is now a question of timing. The only thing still open is whether your migration happens as planned work at your own pace, or as unplanned work when a roadmap item forces it. Most of the difficulty is not writing the new calls. It is knowing which integrations carry real load, which can be retired instead of migrated, and how long the hybrid period will run. That assessment is the platform work that sits behind a storefront rebuild, and a few weeks of it usually saves a few months. A jewellery retailer’s digital commerce build shows how we approach the platform side of that. 

If you are running OCAPI today, start small. Pull thirty days of request volume by endpoint and see how much of your estate is actually live. That number tends to surprise people, and it usually makes the migration look smaller than feared. 

Frequently Asked Questions 

Is OCAPI being switched off, and when? 

Deprecated does not mean switched off. Salesforce marked OCAPI deprecated in April 2026 and says it stays available for two further years with security updates but no new features, so existing integrations keep running. The real deadline is commercial rather than technical, because every new capability now ships to SCAPI only. 

Can we run OCAPI and SCAPI at the same time during a migration? 

Yes, and Salesforce recommends it. SLAS issues a token that works across both API sets, so you can migrate one integration at a time instead of planning a single cutover. Hybrid Auth keeps sessions in sync between legacy SFRA pages and a headless storefront, so baskets are not lost in between. 

Do cartridges still work now that Commerce Apps exist? 

Yes. A Commerce App bundles cartridges together with frontend components, configuration and data into one installable package, so the cartridge is now a part inside a larger unit rather than the unit itself. Existing integrations are not invalidated. The difference shows when you install something new, which becomes a platform managed job instead of a manual upload. 

Does moving to SCAPI mean rebuilding the storefront? 

No. SCAPI is an API layer, not a storefront framework, and an SFRA storefront can call it. The two get bundled together because composable storefronts were the reason SCAPI was built, but they are separate decisions. Treating them as one project is a common way to turn a contained migration into a much longer programme.