Connectors

Salesforce Commerce Cloud

Work with the Salesforce Commerce API (SCAPI) — Shopper APIs (baskets, orders, customers, products, search) and Data/Admin APIs (catalogs, products, promotions, coupons). Covers SLAS vs Account Manager tokens, per-module base URLs, and the organizationId / siteId scoping.

On this page

Connecting Salesforce Commerce Cloud Everything is scoped by tenant and site How the actions are structured Reading the response Auth (SLAS) & Auth Admin Shopper — Baskets, Orders, Customers Shopper — Products & Search Data API — Catalogs, Products, Promotions, Coupons Data API — Infrastructure Generic Request Step Name Step Reference Execution Settings Caching Locking

Connecting Salesforce Commerce Cloud

This connector covers the Salesforce Commerce API (SCAPI) — both the Shopper APIs (customer-facing: browse, basket, order, customer, search) and the Data/Admin APIs (catalogs, products, promotions, coupons, customers, orders).

Every action needs an SFCC connection with an OAuth 2.0 access token:

Shopper APIs use a SLAS (Shopper Login and API Access Service) token. Get one with the Auth (SLAS) actions — typically Get Access Token (POST /organizations/{organizationId}/oauth2/token) with grant_type=client_credentials (for headless/backend) or the guest/registered shopper flow. The token is a Bearer token on subsequent Shopper calls.
Data/Admin APIs use an Account Manager OAuth token (client credentials against https://account.demandware.com/dwsso/oauth2/access_token with the SALESFORCE_COMMERCE_API:<tenant> scope). Supply it as the connection's Bearer token.

Everything is scoped by tenant and site

Base URL — SCAPI hosts are https://<shortCode>.api.commercecloud.salesforce.com/..., and each module hits a different path (e.g. Shopper Products is .../product/shopper-products/v1, Data Products is .../product/products/v1). Each action ships its module's server URL; replace <shortCode> with your realm's short code via the Base URL field (pick Custom).
organizationId — a required path parameter on every action, of the form f_ecom_<realm>_<instance> (e.g. f_ecom_zzte_053).
siteId — a required query parameter on most Shopper and many Data actions — your site id (e.g. RefArch). Add it via Additional Query Parameters if there's no dedicated field.
clientId — some Shopper GETs need a clientId query parameter; use your SLAS client id.

How the actions are structured

30+ picker groups (plus Generic Request), split into:

Shopper: Auth (SLAS), Auth Admin, Baskets v1, Baskets v2, Orders, Customers, Products, Search, Promotions, Gift Certificates, Context, Consents, Configurations, Experience, Stores, SEO, Availability.
Data API: Catalogs, Products, Customers, Orders, Promotions, Coupons, Gift Certificates, Campaigns, Source Code Groups, Zones (CDN), Assignments, Preferences, CORS.

Reading the response

Every action's result is at {{<stepReference>.response...}} (see Step Reference): {{<stepReference>.response.status}}, {{<stepReference>.response.headers.<name>}}, and {{<stepReference>.response.data...}} for the body.

A single resource — fields directly under data, e.g. {{getProduct.response.data.id}}, {{getProduct.response.data.name}}, {{getProduct.response.data.price}}, plus {{<stepReference>.response.data._type}}.
A collection — {{<stepReference>.response.data.data}} is the array (SCAPI's own data key, nested under the envelope's), with {{<stepReference>.response.data.total}}, {{<stepReference>.response.data.count}}, and (search) {{<stepReference>.response.data.hits}}. Page with offset + limit (max 200) via Additional Query Parameters.
A basket / order — the whole object under data (basketId / orderNo, productItems, shipments, paymentInstruments, orderTotal); mutations return the updated basket.
Token endpoints — {{<stepReference>.response.data.access_token}}, {{<stepReference>.response.data.expires_in}}, {{<stepReference>.response.data.refresh_token}}, {{<stepReference>.response.data.usid}}.

A non-2xx response does not fail the step — SCAPI's RFC-7807 error body ({{<stepReference>.response.data.title}}, {{<stepReference>.response.data.detail}}, {{<stepReference>.response.data.type}}) is returned with the real status.

Auth (SLAS) & Auth Admin

The token lifecycle — Get Access Token, Authenticate Customer, Authorize Customer (PKCE), passwordless login, session-bridge and trusted-system/agent tokens, logout, and password reset (/oauth2/password/reset → /oauth2/password/action). Auth Admin manages SLAS clients and tenants.

Shopper — Baskets, Orders, Customers

Baskets v1 / v2 — create a basket, add/update/remove items, set shipping method, add coupons, set billing address and payment instruments, then transfer/merge. v2 adds price-book and taxation refinements. (~37 / ~38 actions.)
Orders — POST .../orders (create an order from a basket), GET .../orders/{orderNo}, payment-instrument management, and payment-method listing.
Customers — register, get/update profile, addresses, payment instruments, product lists (wishlists), and order history. (~33 actions.)

Shopper — Products & Search

Products — getProducts (multiple by id), getProduct, getProductImages, getProductPrices, getProductPromotions, getCategories, getCategory.
Search — productSearch (the storefront search/refinement endpoint — q, refine, sort, offset, limit), getSearchSuggestions.
Promotions — getPromotions (by id list), getPromotionsForCampaign.

Data API — Catalogs, Products, Promotions, Coupons

Catalogs — categories, catalog assignments, shared product options, category-product assignment search. (~32 actions.)
Products — full CRUD on /products/{productId} (PUT create-or-overwrite, PATCH partial update, DELETE), variation groups and variations, variant search, inventory, images, and bulk operations. (~36 actions.)
Promotions / Coupons / Campaigns / Gift Certificates / Source Code Groups — CRUD + search for each pricing object.
Customers (Data) — customer-list management and customer search across a customer list.
Orders (Data) — order search, order-status updates, payment/shipment status.

Data API — Infrastructure

Zones — the CDN/eCDN configuration surface (~77 actions): zones, firewall rules, rate limits, WAF, custom hostnames, certificates, cache settings, page-rules.
Preferences — site and global preference groups.
CORS, Assignments (promotion/campaign assignment) — small config surfaces.

Generic Request

Five actions — Generic GET / POST / PUT / PATCH / DELETE Request — for any SCAPI endpoint not surfaced as a dedicated action.

path — required, relative to the selected Base URL, e.g. /organizations/<orgId>/baskets/<basketId>/price-books. Remember the siteId / clientId query parameters.
Supply the right Bearer token for Shopper vs Data endpoints.

Also applies here

Step Name

What it's for

Every step in a workflow gets a name — either one you set or a default based on the connector and action (e.g. "Get Order Details", "Send Welcome Email"). It's shown throughout the UI and in your execution history, and it's also the source for the step's Reference — a camelCase identifier auto-generated from the name (e.g. "Get Order Details" → getOrderDetails) — which is what you actually use in {{...}} expressions to read this step's output from later steps. See Step Reference.

Rules

Must be at least 2 characters, and 50 characters or fewer.
Must be unique within the workflow — reusing a name that's already taken will be rejected, with a suggested alternative (e.g. "Get Order Details 2").
Can't be empty.

Tips

Prefer a descriptive, human-readable name over a generic one — "Get Order Details" is easier to work with later than "HTTP Request 2", especially once a workflow has a dozen steps.
Renaming a step updates every reference to it elsewhere in the workflow automatically.

Step Reference

Syntax

Any input field can reference earlier data using {{expression}}. The expression is evaluated as JSONata — so simple dot-paths and more advanced queries (filters, functions) both work.

Referencing a step's output

Use the step's Reference — a camelCase identifier auto-generated from its Name (e.g. "Get Order Details" → getOrderDetails), shown read-only wherever the step's fields are configured — followed by the field path. Elsewhere in these docs this general pattern is written as {{<stepReference>.field.path}}:

{{getOrderDetails.response.data.id}}
{{getOrderDetails.response.status}}

The raw display name won't work here even though it's what you see in the UI — {{Get Order Details.response.data.id}} isn't valid, since a bare name containing spaces isn't a single JSONata identifier. Always use the camelCase Reference.

You can also reference steps by position instead of by reference:

{{steps[0].response.data.id}}

Referencing trigger data

{{trigger.headers.authorization}}
{{trigger.body.customerId}}
{{trigger.query.page}}
{{trigger.params.orderId}}
{{trigger.method}}
{{trigger.path}}

Referencing workflow variables

{{variables.myVariable}}

See Variables for the full list of variable types and more examples, including connection-type variables.

Referencing runtime variables

A separate, mutable namespace written by the Variable connector while a run is in progress — not the same as the workflow-level variables above:

{{runtimeVariables.myVariable}}

Notes

If an expression can't be resolved (a typo in a step name, a field that doesn't exist), it resolves to an empty string rather than failing the workflow — check your execution history if a value comes through blank.
Object values are automatically JSON-stringified when interpolated into a string field.

Execution Settings

Fire-and-forget

When enabled, the workflow doesn't wait for this step to complete before moving to the next one. Use it for steps whose result nothing downstream depends on — logging, analytics, notifications — so they don't add latency to the steps that matter.

Continue on error

When enabled, a failure in this step doesn't stop the workflow — execution continues to the next step. The failure is still recorded in the execution history; this just controls whether it's fatal.

Combine the two for steps that are genuinely optional to the outcome: fire-and-forget so they don't add latency, continue-on-error so a failure in them (e.g. an analytics endpoint being briefly down) doesn't take down an otherwise-successful workflow run.

Caching

What it does

When enabled, a step's result is cached for a configurable TTL (time-to-live, in seconds). If the step runs again with the same effective cache key before the TTL expires, the cached result is returned instead of re-running the step.

Configuring it

Enabled — turn caching on or off for this step.
TTL — how long (in seconds) a cached result stays valid.
Cache key template — an expression (supporting the same {{...}} step reference syntax used elsewhere) that determines what counts as "the same call". By default this is based on the step's resolved input; a custom template lets you cache more narrowly or broadly than that.

When to use it

Good candidates are steps that call something slow or rate-limited but return the same answer for the same input within a short window — a lookup against a rarely-changing external system, for example. Skip it for steps whose result must always be fresh (anything involving live inventory, pricing, or payment state).

Locking

What it does

When enabled, only one execution of this step (for a given lock key) can run at a time. If a second execution tries to run the same step while a lock is held, it waits until the lock is released or the hold period elapses.

Configuring it

Enabled — turn locking on or off for this step.
Lock key — an expression (supporting the same {{...}} step reference syntax used elsewhere) that determines what counts as "the same resource". By default the lock is scoped to the step itself; a custom key lets you lock per-customer, per-order, or any other identifier that needs serialized access.
Period — how long (in seconds) the lock is held before it's automatically released, in case an execution doesn't complete normally.

When to use it

Use it whenever concurrent executions could race on the same resource — e.g. two workflow runs both trying to update the same order's status at once. A lock key scoped to the order id ensures only one of them proceeds at a time.