Connectors

Shopify Storefront

Access the Shopify Storefront GraphQL API — product and collection browsing, carts, and customer accounts. Covers the editable query + variables model, global ids, cursor pagination, and the two error paths (GraphQL errors vs. mutation userErrors).

On this page

Connecting Shopify Storefront How the actions work Reading the response Products & Collections Cart Customer Shop Storefront: Execute GraphQL Query Step Name Step Reference Execution Settings Caching Locking

Connecting Shopify Storefront

Every action needs a Shopify Storefront connection configured with:

Shop Domain — your .myshopify.com domain, without https://.
Storefront API Access Token — a Storefront access token (not an Admin token), created in your Shopify admin under Settings → Apps and sales channels → Develop apps → your app → API credentials → Storefront API access token. It's sent as the X-Shopify-Storefront-Access-Token header automatically.

All actions POST to the Storefront GraphQL endpoint https://<shop-domain>/api/2026-07/graphql.json. This is the customer-facing API — product browsing, carts, and customer accounts — not store management (use the Shopify (Admin) connector for products, orders, inventory, etc.).

How the actions work

Every action has two fields:

GraphQL Query / GraphQL Mutation — a full, editable GraphQL document. Each action ships a sensible default that selects a useful set of fields; edit it to request more or fewer fields, or to change the operation entirely.
Variables — an editable JSON object of the query's variables. Each action ships a default with placeholder values (gid://shopify/... ids, REPLACE_WITH_ACCESS_TOKEN, etc.) — replace these with real values or {{<stepReference>...}} expressions.

Shopify ids are global ids (gid://shopify/Product/123456, gid://shopify/Cart/abc123), not bare numbers.

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...}} — where data is the GraphQL response's data payload, keyed by the operation's root field. So a "List Products" step (reference storefrontListProducts) resolves its product edges at {{storefrontListProducts.response.data.products.edges}} (each edge is { cursor, node }) and the next-page flag at {{storefrontListProducts.response.data.products.pageInfo.hasNextPage}}.

Two error paths, and they behave differently:

GraphQL-level errors (a malformed query, an unknown field) — the connector throws, so the step fails. There is no {{<stepReference>.response...}} to read.
Mutation userErrors (business validation — invalid discount code, out-of-stock variant) — returned normally. Always check {{<stepReference>.response.data.<rootField>.userErrors}} after a mutation before assuming it worked.

Cursor pagination: pass the previous response's pageInfo.endCursor back as the after variable.

Products & Collections

Storefront: List Products — root products. Variables: first (page size), query (Shopify search syntax, e.g. "tag:sale vendor:Nike"), sortKey (RELEVANCE, BEST_SELLING, PRICE, CREATED_AT, TITLE), reverse, after.
Storefront: Get Product — root product. Variables: id (gid://shopify/Product/...).
Storefront: Get Product Recommendations — root productRecommendations (an array). Variables: productId.
Storefront: List Collections — root collections. Variables: first, after, query.
Storefront: Get Collection — root collection, with a nested products connection. Variables: id, productsFirst, productsAfter, productsSortKey (COLLECTION_DEFAULT, PRICE, BEST_SELLING, …).
Storefront: Collection With Filters — same as Get Collection plus a filters variable (array of Storefront ProductFilter objects, e.g. [{ "available": true }, { "price": { "min": 10, "max": 50 } }]); the response also returns the available filters facets.

Cart

Storefront: Create Cart — mutation cartCreate. Variables: input — { "lines": [ { "merchandiseId": "gid://shopify/ProductVariant/...", "quantity": 1 } ], "discountCodes": [...], "buyerIdentity": {...}, "attributes": [...] }. Read the new cart id from {{<stepReference>.response.data.cartCreate.cart.id}} and the checkout URL from {{<stepReference>.response.data.cartCreate.cart.checkoutUrl}}.
Storefront: Get Cart — query, root cart. Variables: cartId.
Storefront: Add Items to Cart — mutation cartLinesAdd. Variables: cartId, lines (array of { merchandiseId, quantity }).
Storefront: Update Cart Lines — mutation cartLinesUpdate. Variables: cartId, lines (array of { id (the CartLine gid), quantity }).
Storefront: Remove Cart Lines — mutation cartLinesRemove. Variables: cartId, lineIds (array of CartLine gids).
Storefront: Apply Discount to Cart — mutation cartDiscountCodesUpdate. Variables: cartId, discountCodes (array of strings — replaces the set; [] clears them). Check {{<stepReference>.response.data.cartDiscountCodesUpdate.cart.discountCodes}} for which applied (applicable: true).
Storefront: Update Cart Buyer Identity — mutation cartBuyerIdentityUpdate. Variables: cartId, buyerIdentity ({ email, phone, countryCode, customerAccessToken, deliveryAddressPreferences }).

All cart mutations return { cart, userErrors } under their root field.

Customer

These operate on customer accounts. A customer access token identifies the logged-in customer — get one with Customer Login, then pass it as the customerAccessToken variable to the others.

Storefront: Customer Login — mutation customerAccessTokenCreate. Variables: input ({ email, password }). Returns {{<stepReference>.response.data.customerAccessTokenCreate.customerAccessToken}} ({ accessToken, expiresAt }) plus customerUserErrors.
Storefront: Customer Logout — mutation customerAccessTokenDelete. Variables: customerAccessToken.
Storefront: Register Customer — mutation customerCreate. Variables: input ({ email, password, firstName, lastName, phone, acceptsMarketing }).
Storefront: Get Customer — query, root customer. Variables: customerAccessToken, ordersFirst (how many recent orders to include).
Storefront: Update Customer — mutation customerUpdate. Variables: customerAccessToken, customer ({ firstName, lastName, email, phone, password, acceptsMarketing }).
Storefront: Send Password Reset — mutation customerRecover. Variables: email. Triggers Shopify's password-reset email.
Storefront: Add Customer Address — mutation customerAddressCreate. Variables: customerAccessToken, address (MailingAddressInput — address1, address2, city, province, country, zip, phone, …).
Storefront: Set Default Address — mutation customerDefaultAddressUpdate. Variables: customerAccessToken, addressId (gid://shopify/MailingAddress/...).

Shop

Storefront: Get Shop Info — query GetShop, root shop. No variables. Returns name, primaryDomain, paymentSettings, shipsToCountries, policies, etc.

Storefront: Execute GraphQL Query

The escape hatch. Run any Storefront query or mutation.

GraphQL Query — required, the query/mutation string (no default).
Variables — a JSON object, e.g. {"first": 10}.

Read the result at {{<stepReference>.response.data.<yourRootField>...}}. Same error behavior as the dedicated actions (GraphQL errors fail the step).

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.