Connectors

Elastic Path

Work with Elastic Path Commerce Cloud's full API — carts, catalog and catalog search, PIM, price books, inventory, promotions, accounts, flows, integrations, and subscriptions. Covers client-credentials auth, region base URLs, and the JSON:API response shape.

On this page

Connecting Elastic Path How Elastic Path actions are structured Reading the response Carts Catalog & Catalog Search PIM & Catalog Composition Price Books Inventory Promotions & Promotions Builder Accounts, Addresses, Auth Platform Subscriptions Generic Request Step Name Step Reference Execution Settings Caching Locking

Connecting Elastic Path

Every action needs an Elastic Path connection configured with OAuth 2.0 client-credentials (an API key's client id + client secret from Application Keys in Commerce Manager). The connector exchanges them for an access token and sends it as a Bearer token automatically.

Base URL — every action offers a Base URL dropdown: https://useast.api.elasticpath.com (US) or https://euwest.api.elasticpath.com (EU). Pick your store's region.
Store context — most catalog reads are served "as a shopper" against a published catalog; pass the EP-Channel and EP-Context-Tag headers (or channel / tag params) via Additional Headers / Additional Query Parameters when you need a specific catalog rules context.

How Elastic Path actions are structured

Each action is one Commerce Cloud operation, grouped in the picker by product area (~27 groups plus Generic Request):

Storefront / runtime: Carts, Catalog, Catalog Search, Payments, Account Addresses, Customer Addresses, Currencies.
Accounts & auth: Accounts, Authentication, Application Keys, Permissions, Single Sign-On, Personal Data.
PIM & pricing: PIM, Price Books, Catalog (composition), Inventory, Inventory (Legacy).
Merchandising: Promotions, Promotions Builder.
Platform: Flows (custom fields / custom objects), Integrations (webhooks), Commerce Extensions, Files, Settings, Exporter, Merchant Realm Mappings.

Different areas use different path prefixes (/v2/..., /catalog/..., /pcm/..., /pricebooks/..., /settings/...) — the action's spec sets it; path parameters (cartID, product_id, node_id, account_id, pricebook_id, offering_uuid, …) are dedicated fields.

Reading the response

Elastic Path is a JSON:API-style API. 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 — {{<stepReference>.response.data.data}} is the resource (note the doubled .data), with id, type, attributes ({{<stepReference>.response.data.data.attributes.name}}), relationships, and meta. Related resources are in {{<stepReference>.response.data.included}} when include is requested.
A collection — {{<stepReference>.response.data.data}} is the array; {{<stepReference>.response.data.meta.page}} (total, current, limit) and {{<stepReference>.response.data.links}} describe paging. Page with page[limit] (max 100) + page[offset] via Additional Query Parameters; filter with filter = eq(name,'Shoe').
Carts — {{<stepReference>.response.data.data}} is the cart; cart items and totals are in included / meta.display_price.

A non-2xx response does not fail the step — Elastic Path's error body ({{<stepReference>.response.data.errors}}, each { status, title, detail, meta }) is returned with the real status.

Carts

The runtime cart API (~60 actions). POST /v2/carts (create), GET|PUT|DELETE /v2/carts/{cartID}, GET /v2/carts (list a customer's/account's carts). Items: GET|POST|PUT|DELETE /v2/carts/{cartID}/items (add uses manageCarts; PUT is a bulk update), PUT|DELETE /v2/carts/{cartID}/items/{cartitemID}. Plus: promotion codes (DELETE .../discounts/{promoCode}), custom discounts, tax items, shipping groups, and account/customer cart associations (POST|DELETE /v2/carts/{cartID}/relationships/{accounts|customers}). Convert a cart to an order via the Payments / checkout flow.

Catalog & Catalog Search

Catalog (~46) — the shopper-facing published catalog: GET /catalog (release), /catalog/hierarchies, /catalog/nodes, /catalog/products, /catalog/products/{product_id}, child-node and node-product relationships, and product component/variation reads.
Catalog Search (~28) — POST search endpoints over the published catalog with facets, filters, sort, and pagination.

PIM & Catalog Composition

PIM (~82) — the product master data: GET|POST /pcm/products, GET|PUT|DELETE /pcm/products/{productID}, product import, bundles, variations & variation options, product templates (/pcm/settings/*), hierarchies & nodes (/pcm/hierarchies), and async jobs (/pcm/jobs).
Catalog composition — publishing rules that turn PIM data + price books + a hierarchy into a published catalog release.

Price Books

GET|POST /pricebooks, GET|PUT|DELETE /pricebooks/{pricebook_id}, and per-price-book prices (GET|POST /pricebooks/{pricebook_id}/prices, GET|PUT|DELETE .../prices/{price_id}), plus price-book import.

Inventory

/v2/inventories (and the legacy /v2/inventory API) — get stock for a product, increment/decrement/allocate/deallocate stock transactions, and location-aware multi-location inventory.

Promotions & Promotions Builder

Promotions (v2) — GET|POST /v2/promotions, GET|PUT|DELETE /v2/promotions/{promotion_id}, promotion codes (/codes).
Promotions Builder — the newer rules-engine promotions: rule sets, campaigns, and code management.

Accounts, Addresses, Auth

Accounts (~28) — B2B account management: accounts, account members, account membership, and account authentication settings.
Account Addresses / Customer Addresses — CRUD on /v2/accounts/{account_id}/addresses and /v2/customers/{customer_id}/addresses.
Authentication / Single Sign-On — customer/account authentication realms, password profiles, OIDC profiles.
Application Keys, Permissions, Personal Data (GDPR export/erase).

Platform

Flows — define custom fields on core resources and standalone custom objects; then CRUD entries.
Integrations — webhook subscriptions and event logs.
Commerce Extensions — custom data models with their own records and relationships.
Files — upload and manage media; Settings, Currencies, Exporter, Merchant Realm Mappings.

Subscriptions

A large module (~85 actions): offerings (/v2/subscriptions/offerings, features, pricing options), plans, products, subscriptions (/v2/subscriptions/subscriptions — create, pause, resume, cancel), subscribers, and invoices.

Generic Request

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

path — required, relative to the selected Base URL, e.g. /v2/orders, /v2/customers, /settings/store, /pcm/pricebooks.
Request Body (Raw) — a JSON:API document ({ "data": { "type": "...", "attributes": {...} } }).

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.