B2C Commerce ships with two API surfaces. OCAPI is the older REST API, mature and widely integrated. SCAPI is the newer Commerce API, the Salesforce-recommended path. They overlap; they are not interchangeable; the choice affects 2-year integration plans.
B2C Commerce ships with two API surfaces. OCAPI (Open Commerce API), the older REST API introduced over a decade ago, mature and integrated into hundreds of customer and partner systems. SCAPI (Salesforce Commerce API), the newer headless-friendly API introduced in 2021, OAuth-based, the Salesforce-recommended path going forward.
The two overlap in capability but differ in authentication model, request shape, and roadmap support. New integrations face a real choice. Existing OCAPI integrations face an eventual migration question.
Sapota's Salesforce team has built integrations on both APIs and has run migrations between them. The decision criteria below are what we apply during integration design on B2C Commerce engagements.
OCAPI has three flavors:
Authentication: client credentials (BM user grants), JWT bearer tokens, or session-based for storefront. Predominantly REST with JSON.
SCAPI consists of multiple APIs under a unified umbrella:
Authentication: OAuth 2.0 with the Shopper Login and API Access Service (SLAS) for shopper APIs, OAuth client credentials for admin. JSON over HTTPS. OpenAPI 3.0 specs published.
For common operations, both APIs work:
| Operation | OCAPI | SCAPI |
|---|---|---|
| Read product details | Shop API | Shopper Products |
| Search products | Shop API | Shopper Search |
| Manage basket | Shop API | Shopper Baskets |
| Place order | Shop API | Shopper Orders |
| Register customer | Shop API | Shopper Customers |
| Authenticate shopper | Shop API | Shopper Login (SLAS) |
| Admin data updates | Data API | Admin APIs |
For these operations, the choice is more about which API your team and integrations are already invested in than about capability.
OAuth 2.0 and SLAS. SCAPI's Shopper Login and API Access Service is purpose-built for headless storefront authentication. Supports guest sessions, registered shopper login, social login, and refresh tokens. OCAPI's auth model was bolt-on to the older API.
OpenAPI 3.0 specs. SCAPI publishes formal OpenAPI specs. Client code can be generated automatically. OCAPI has documentation but no formal spec.
Headless storefront posture. SCAPI is designed for headless. Composable Storefront (formerly PWA Kit) uses SCAPI exclusively. OCAPI works for headless but predates the architecture.
Pricing and promotions in headless contexts. SCAPI's basket and order APIs handle promotion evaluation in a way that fits headless flows better. OCAPI Shop API works but the promotion model assumes more of a server-rendered storefront.
AI/ML endpoints. SCAPI has dedicated endpoints for Einstein commerce features. OCAPI does not.
Roadmap investment. Salesforce concentrates new feature work on SCAPI. New APIs (like Catalog Management, Inventory) are SCAPI-only.
Three scenarios:
1. Building a headless storefront or Composable Storefront. Use SCAPI. The headless architecture is what SCAPI was designed for. Composable Storefront supports it natively.
2. New integration for an internal system (ERP, OMS, BI). Use SCAPI Admin APIs. The OAuth model fits modern service-to-service patterns. The OpenAPI specs accelerate development.
3. Extending an existing OCAPI integration. If the integration is already on OCAPI and the new functionality exists in OCAPI Shop or Data API, stay on OCAPI for consistency. Plan a migration in a separate effort.
The default for new work in 2026: SCAPI.
OCAPI is not deprecated. Several scenarios still favor it:
1. Existing OCAPI integration in production. Migrating to SCAPI is real work. Unless there is a specific SCAPI capability needed, the existing OCAPI integration can stay.
2. Capabilities only OCAPI exposes. Some lower-level data operations are richer in OCAPI Data API. Inventory list management, certain catalog manipulation patterns are more flexible in OCAPI as of writing.
3. Tooling already built around OCAPI. Custom monitoring, custom debugging tools, custom client libraries built on OCAPI represent investment. Migrating them takes time.
The pragmatic question: is the cost of migrating worth the benefit? For most production OCAPI integrations, the answer is "not yet, but plan for it."
OCAPI client credentials. A BM user issued an API client ID and password. The client authenticates via the password and requests OAuth tokens. Tokens have configurable lifetimes. Common in admin-side integrations.
SCAPI OAuth 2.0 client credentials. Service-to-service auth using OAuth standard. Client ID and secret managed in the Account Manager. Tokens via standard token endpoint. Refresh tokens for long-lived sessions.
SLAS for shoppers. Headless storefronts authenticate guest and registered shoppers via SLAS. Returns JWT tokens. Refresh flow standard.
The takeaway: SCAPI auth follows modern OAuth patterns. OCAPI auth predates them. SCAPI is easier to integrate into systems that already use OAuth.
Migrating an integration from OCAPI to SCAPI:
Endpoint mapping. Each OCAPI endpoint has a SCAPI equivalent (with some exceptions). Map them explicitly.
Request and response shape differences. Some shapes differ (e.g., basket items, address structures). Adapter layer between the integration's internal model and SCAPI.
Authentication overhaul. Auth code changes from OCAPI's pattern to OAuth 2.0. Larger change than the endpoint switch.
Testing the parallel. Run both APIs against the same operations in staging. Compare results. Resolve discrepancies before cutover.
Cutover strategy. Feature-flag the integration: half traffic on OCAPI, half on SCAPI. Monitor for drift. Migrate fully when confident.
Realistic migration timeline for a moderate OCAPI integration: 3 to 6 months including testing and rollout. Plan accordingly.
Five patterns Sapota has seen on engagements:
1. Defaulting to OCAPI because tutorials are older. Stack Overflow answers and Salesforce docs from years past assume OCAPI. New teams follow them and end up on the older API. Check the date of any reference doc.
2. Mixing both APIs in one integration. Calls to OCAPI Shop API in one place, SCAPI in another, no clear pattern. Maintenance burden. Pick one for each integration.
3. SCAPI without SLAS for headless. A team builds a headless storefront on SCAPI but uses OCAPI session auth. The architecture is mismatched. SLAS is part of the SCAPI stack.
4. OCAPI integration that ignores OAuth token refresh. Tokens expire; integration breaks after the first expiry. Implement refresh from day one.
5. No retry on transient failures. Both APIs occasionally return 503s or rate limit responses. Integrations without backoff hammer the API and amplify the failure. Use exponential backoff.
A B2C Commerce program with healthy API discipline:
The OCAPI-to-SCAPI shift is one of those platform transitions that happens slowly and then suddenly. Programs that plan for it stay ahead. Sapota's Salesforce team has run integration design and migrations on both APIs across retail, B2B, and headless engagements.
Choosing or migrating between OCAPI and SCAPI? Sapota's Salesforce team, certified on B2C Commerce Developer (Comm-Dev-101), handles B2C Commerce API integration design, OAuth flows, and SCAPI migrations on production engagements. Get in touch ->
See our full platform services for the stack we cover.
Other posts in the same topical cluster. The pattern in the post above usually shows up alongside the patterns below, either because they live on the same surface of the platform or because the same engagement type runs into both. Pick the one closest to the problem in front of you and start there.
B2C CommerceMay 28, 2026
Catalog imports, inventory feeds, customer exports, email batches. Every B2C Commerce site has dozens of jobs running on schedules. The framework is powerful and easy to misuse. The patterns that produce reliable jobs are not the defaults.
Read More
B2C CommerceMay 24, 2026
Hooks are the supported extension mechanism for B2C Commerce. They let custom code run at specific points in the platform's lifecycle without modifying base code. Used right, they survive every platform upgrade. Used wrong, they reintroduce the customization debt SFRA was meant to solve.
Read More
B2C CommerceMay 27, 2026
A retail brand runs 3 sites: domestic, regional, and B2B. Each needs its own pricing, currency, locale, and customer experience. The catalog and inventory questions decide whether the architecture scales or fragments over time.
Read More
B2C CommerceMay 22, 2026
Every B2C Commerce site calls external systems: payment gateways, tax engines, OMS, marketing platforms. The services framework wraps these calls with circuit breakers, profiles, and credentials. Used badly, it produces incidents. Used well, it survives bad afternoons.
Read MoreWe build trust by delivering what we promise – the first time and every time!
We'd love to hear your vision. Our IT experts will reach out to you during business hours to discuss making it happen.
"Collaborate, Elevate, Celebrate where Associates - Create Project Excellence"
SapotaCorp beyond the IT industry standard, we are
