B2C SCAPI Schemas Skill
Browse standard or tenant-specific SCAPI OpenAPI contracts.
Tool choice
When B2C MCP is available, prefer scapi_search for Admin and Shopper contracts.
Read skill://mcp/b2c-mcp-scapi/SKILL.md via resource or skills_read first; pass
skillRead: true. Discover method/path/operationId, then selected inputs and
fields. The default searches bundled standard contracts offline; schemas: "live"
searches the tenant's contracts (custom attributes, custom APIs, newer APIs) and
makes them callable from scapi_execute.
Use scapi_schemas_list for live schemas, custom attributes, and custom APIs.
For tenant fields, supply API family/name/version and includeSchemas: true.
Custom-property expansion defaults to true; expandAll: true preserves full definitions.
For large schemas, fetch/filter through code mode as described in the MCP SCAPI skill.
Use scapi_custom_apis_get_status for registration status. Live schema access needs
sfcc.scapi-schemas. Prefer a dedicated task tool for execution, otherwise
scapi_execute supports Admin and guest Shopper JSON calls with configured auth/scopes. For custom
Admin endpoints, fetch the live contract through scapi.request in each program
before calling it; follow the MCP SCAPI skill. Registered-shopper and binary execution are
unsupported. Use docs tools for semantics
and limits rather than duplicating contract discovery.
For CLI work, use b2c scapi schemas list and
b2c scapi schemas get <family> <name> <version>; both use live access.
CLI get expands custom properties by default; --no-expand-custom-properties
requests the standard contract. MCP also defaults to expansion; disable it with
expandCustomProperties: false. Known custom fields can be sent through standard
Admin code-mode requests without a schema read or offline refresh.
config_inspect is the masked MCP equivalent of b2c setup inspect.
Read CLI examples for filters, selective expansion,
custom properties, and file output. There is no CLI code-mode equivalent.
Tip: If
b2cis not installed globally, usenpx @salesforce/b2c-cliinstead (e.g.,npx @salesforce/b2c-cli scapi schemas list).
Configuration
Values like tenantId, shortCode, clientId, and clientSecret resolve from dw.json / SFCC_* env vars / the active instance / configuration plugins. Examples below show minimal usage; add flags only to override configured values — passing --client-id/--client-secret/--tenant-id/--short-code is usually unnecessary. If a required value is missing, the CLI emits an actionable error pointing at the flag, env var, and config key.
Run b2c setup inspect to see the resolved configuration and which source provided each value (--json for scripting; secrets stay masked by default). For precedence rules and troubleshooting, see the b2c-cli:b2c-config skill.
Tenant ID vs. Organization ID
The tenant ID identifies your B2C Commerce instance for SCAPI calls. It is not the same as the organization ID:
- Tenant ID:
zzxy_prd(thetenantIdvalue in dw.json, or--tenant-idoverride) - Organization ID:
f_ecom_zzxy_prd(used in SCAPI URLs, hasf_ecom_prefix)
Deriving Tenant ID from Hostname
For sandbox instances, derive the tenant ID from the hostname by replacing hyphens with underscores:
| Hostname | Tenant ID |
| ------------------------------------------ | ---------- |
| zzpq-013.dx.commercecloud.salesforce.com | zzpq_013 |
| zzxy-001.dx.commercecloud.salesforce.com | zzxy_001 |
| abcd-dev.dx.commercecloud.salesforce.com | abcd_dev |
For production instances, use your realm and instance identifier (e.g., zzxy_prd).