dist/codex/salesforce-commerce/skills/sf-b2c-ocapi/SKILL.md
"MIGRATION SKILL: OCAPI (Open Commerce API) — Shop API and Data API endpoints, authentication, pagination, and OCAPI-to-SCAPI migration guide. OCAPI is in maintenance-only mode with no new features. Use this skill only for maintaining legacy integrations or planning migration to SCAPI."
npx skillsauth add orcaqubits/agentic-commerce-claude-plugins sf-b2c-ocapiInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
MAINTENANCE-ONLY NOTICE
OCAPI is in maintenance-only mode. Salesforce is not adding new features and has positioned SCAPI as the successor for all new storefront development. OCAPI receives only critical security patches and bug fixes. It has NOT been formally deprecated with a sunset date.
Use this skill ONLY for: maintaining legacy integrations, planning OCAPI-to-SCAPI migration, or debugging production OCAPI issues.
Do NOT build new features against OCAPI. Use the
sf-b2c-scapiskill for all new work.
Fetch live documentation BEFORE writing any code.
site:developer.salesforce.com OCAPI reference B2C Commerce for latest reference docssite:developer.salesforce.com SCAPI migration OCAPI for migration guidesSalesforce B2C Commerce OCAPI maintenance mode 2026 for deprecation timeline updatesdeveloper.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-ocapi-overview.html| Aspect | Shop API | Data API |
|--------|----------|----------|
| Purpose | Storefront operations (browse, cart, checkout) | Admin/integration operations (catalog, config, batch) |
| Audience | Shoppers / frontend apps | Admins / ERP / PIM integrations |
| Site scope | Site-specific (/s/{site_id}/dw/shop/) | Global (/s/-/dw/data/) |
| Auth | Client ID header or customer JWT | JWT bearer token from Account Manager |
| Typical consumers | PWA, mobile apps, kiosks | ERP connectors, OMS, back-office tools |
| Auth Type | API | Use Case |
|-----------|-----|----------|
| Client ID header (x-dw-client-id) | Shop API | Anonymous browsing |
| Customer JWT (via /customers/auth) | Shop API | Registered customer sessions |
| OAuth JWT (Account Manager) | Data API | Server-to-server integrations |
| BM User Grant | Data API | Operations requiring BM user context |
Access control is configured via JSON in Business Manager, granting each client specific resources and methods.
OCAPI uses offset-based pagination with count (page size) and start (offset) parameters. Responses include total, hits, next, and previous fields.
| Parameter | Default | Description |
|-----------|---------|-------------|
| count | 25 | Results per page (max varies, typically 200) |
| start | 0 | Zero-based offset |
Use the expand parameter to include related data (images, prices, variations) in a single request, reducing round-trips. Use select to request only needed fields, reducing payload size.
OCAPI requires an explicit version in the URL path (e.g., v24.5). Each B2C Commerce release may introduce a new version. Pin your version and do not upgrade unless required for a security patch.
| Aspect | OCAPI | SCAPI |
|--------|-------|-------|
| Auth | Client ID header + Basic auth | SLAS (OAuth 2.1 with PKCE) |
| Naming | snake_case fields | camelCase fields |
| Versioning | Frequent version bumps (v24.5) | Stable (v1) |
| SDK | No official SDK | Commerce SDK (Node.js/TypeScript) |
| CDN | Separate CDN config | eCDN built-in |
| Search | POST with JSON body | GET with query params |
| Status | Maintenance-only | Active development |
Migration should be incremental, not big-bang:
snake_case to camelCase for downstream consumersOCAPI returns faults in a standard envelope with _type: "fault" and a nested fault object containing type and message. Common fault types:
| Fault Type | HTTP Status |
|------------|-------------|
| InvalidParameterException | 400 |
| AuthenticationFailedException | 401 |
| AuthorizationFailedException | 403 |
| NotFoundException | 404 |
| RateLimitExceededException | 429 |
expand to fetch related data in one call instead of multiple requestsFetch the latest OCAPI reference docs, SCAPI migration guide, and Salesforce release notes for exact endpoint schemas, version availability, and deprecation timelines before implementing.
development
Build with Spree's headless Next.js storefront — the official `spree/storefront` repo (Next.js 16 App Router with Server Actions and Turbopack, React 19 Server Components, Tailwind CSS 4, TypeScript 5, `@spree/sdk`, Sentry), server-only auth (httpOnly JWT cookies + publishable key), MeiliSearch faceted catalog, one-page checkout with Apple/Google Pay/Klarna/Affirm/SEPA, multi-region market routing, GA4 + JSON-LD SEO, and Vercel/Docker deployment. Use when forking or customizing the storefront, or evaluating headless adoption.
tools
Build Spree extensions as Rails engines — gem scaffolding, `bin/rails g spree:extension`, mounting routes/migrations/assets, the modern `prepend` decorator pattern (`*_decorator.rb` with `self.prepended(base)`), generators (`spree:model_decorator`, `spree:controller_decorator`), the four customization surfaces in preference order (Events > Webhooks > Dependencies > Decorators), Spree::Dependencies for swapping service objects, gem release/versioning, and the deprecated Deface engine. Use when building a reusable Spree extension or adding non-trivial customization to an app.
development
Build with Spree's event bus and Webhooks 2.0 — `Spree::Events` publication, `Spree::Subscriber` DSL with `subscribes_to` and `on`, wildcard matching, lifecycle events (`{model}.created/.updated/.deleted` via `publishes_lifecycle_events`), the canonical event catalog (order.*, payment.*, shipment.*, product.*), Webhooks 2.0 endpoints, HMAC-SHA256 signing (`X-Spree-Webhook-Signature`), exponential-backoff retries, and Sidekiq job orchestration. Use when wiring event-driven business logic, building webhook consumers, or replacing ActiveSupport callback chains.
tools
Cross-cutting Spree development patterns — the customization preference hierarchy (Events > Webhooks > Dependencies > Decorators), `Spree::Dependencies` service-object swapping, the `_decorator.rb` + `prepend` + `self.prepended` idiom, idempotent subscribers and webhook receivers, multi-store scoping discipline, prefixed IDs, calculator polymorphism (shipping/promotion/tax share the base), service-object composition with `dry-monads` or simple results, why to avoid `class_eval` reopening and Deface, and Spree-on-Rails idioms (Hotwire/Turbo Stimulus, ActiveStorage, Action Cable, Sidekiq). Use when designing the architecture of a Spree extension or solving cross-cutting concerns.