How to Mirror Shopify Price and Cost Changes into Adobe Commerce

Build a Spojit workflow that runs on a schedule, detects products whose price changed in Shopify, and pushes the new price to the matching Adobe Commerce product so both storefronts stay aligned.

What This Integration Does

If you sell the same catalog on Shopify and on Adobe Commerce, prices drift apart the moment someone edits one store and forgets the other. This Spojit workflow makes Shopify the source of truth for pricing: on a fixed schedule it reads your active Shopify products, compares each product's current price to the price you last pushed, and updates the matching Adobe Commerce product whenever the two differ. The result is a hands-off price mirror so a markdown, a margin change, or a promo price set in Shopify reaches Adobe Commerce automatically.

The workflow is driven by a Schedule trigger, so nobody has to start it. Each run reads a page of Shopify products with the shopify connector, looks up the equivalent record in Adobe Commerce by SKU, and calls the adobe-commerce-rest connector to write the new price only when it has actually moved. Products are matched on SKU, which both platforms expose, so the two catalogs do not need to share internal IDs. The workflow holds no long-term state of its own: it reads the live price on both sides every run, which means it is safe to re-run, and a run that finds nothing changed simply does no writes.

Prerequisites

A shopify connection with read access to products (used by list-products and get-product).
An adobe-commerce-rest connection with permission to read and update products (used by get-product and update-product).
A shared identifier between the two stores. This guide matches on sku, so every Shopify variant SKU must correspond to an Adobe Commerce product SKU.
Agreement that Shopify is the pricing source of truth. This workflow writes one direction only: Shopify to Adobe Commerce.
A timezone for the schedule (for example Australia/Sydney) so the sync runs at a predictable local hour.

Step 1: Add a Schedule trigger

Open the Workflow Designer and add a Trigger node, then set its Trigger Type to Schedule. A Schedule trigger uses a 5-field Unix cron expression plus an IANA timezone. To run every weekday at 6 AM, use:

0 6 * * 1-5

Set the timezone to your store's local zone, for example Australia/Sydney. A single Schedule trigger can hold several schedules if you want a morning and an afternoon pass. The trigger output is { scheduledAt }; you do not need to reference it downstream, it just starts the run.

Step 2: Read changed products from Shopify

Add a Connector node in Direct mode, choose the shopify connector, and select the list-products tool. Use Shopify's query syntax in the query field to narrow the set you scan. To pull active products that were updated recently, set:

status:active updated_at:>2026-06-19

Set first to a page size such as 50 (the maximum is 250). list-products returns paginated results; capture the page cursor from pageInfo.endCursor and pass it back into the after field on the next pass to walk the full catalog. Reference the result later as {{ shopify_products.products }} (the name comes from this node's Output Variable). Each product carries its variants, and the price lives on the variant.

Step 3: Loop over each product

Add a Loop node in ForEach mode and point it at the product list from the previous step, for example {{ shopify_products.products }}. Everything inside the loop body runs once per product, with the current item available as the loop item (for example {{ product }}). Inside the loop you will read the matching Adobe Commerce price, compare, and write only when needed. Keeping the comparison inside the loop means each product is evaluated independently, so one missing SKU never blocks the rest.

Step 4: Look up the matching Adobe Commerce product

Inside the loop, add a Connector node in Direct mode, choose the adobe-commerce-rest connector, and select the get-product tool. Adobe Commerce is keyed by SKU, so map the sku field to the current Shopify variant SKU, for example:

{{ product.variants[0].sku }}

The response includes the product's current price and other attributes. Reference it downstream as {{ adobe_product.price }}. If a SKU has no Adobe Commerce match, this call returns an error for that item; handle that with a Condition check or by enabling retry and error handling on the node so the loop continues to the next product.

Step 5: Compare prices and branch

Add a Condition node that compares the live Shopify price to the Adobe Commerce price you just read. The Shopify variant price is a string, so normalize both sides before comparing. A reliable test is whether the two differ:

{{ product.variants[0].price }} is not equal to {{ adobe_product.price }}

If you want to avoid rounding noise, add a Connector node using the math connector's round tool on each value first, then compare the rounded results. Wire the true branch to the update step in Step 6. Leave the false branch empty so unchanged products are skipped with no write, which keeps each run cheap and avoids needless Adobe Commerce API calls.

Step 6: Update the Adobe Commerce price

On the Condition node's true branch, add a Connector node in Direct mode, choose the adobe-commerce-rest connector, and select the update-product tool. Map sku to the same SKU you looked up, and put the new price inside the product object. update-product is a partial update, so send only the price:

{
  "sku": "{{ product.variants[0].sku }}",
  "product": {
    "price": {{ product.variants[0].price }}
  }
}

Adobe Commerce expects price as a number, so make sure the value is not quoted. Because the workflow only reaches this step when the Condition found a real difference, every write is a meaningful price change. The loop then advances to the next product and the run ends when the last item is processed.

Step 7: Notify on changes (optional)

If you want a record of what moved, add a Send Email node after the loop. Send Email uses Spojit's built-in mail service and needs no connection. Set Recipients to your operations inbox, a templated Subject such as Shopify to Adobe price sync complete, and a body summarizing the SKUs you updated. Only upstream variables resolve in the body, so build a running summary inside the loop (for example with a Transform node) and reference it here. External recipients must be on the org allowlist under Settings > General > Email recipients.

Tips

Narrow the Shopify query with updated_at:> so each run only inspects recently changed products instead of the whole catalog. This cuts both runtime and API calls dramatically.
Both list-products on Shopify and list-products on Adobe Commerce paginate. For large catalogs, walk Shopify pages with the after cursor and stop when pageInfo.hasNextPage is false.
Use Direct mode for every connector call here. The comparison is deterministic, so there is no need for Agent mode and no AI credits are spent.
If a product has multiple variants at different prices, decide a rule (for example mirror only the first variant, or map each variant SKU to its own Adobe Commerce product) and reflect it in the SKU you pass to get-product.

Common Pitfalls

SKUs must match exactly. A trailing space or a case difference means get-product on Adobe Commerce returns no match and that product is silently skipped. Trim and normalize SKUs with the text connector if your data is inconsistent.
Shopify variant prices are strings (for example "19.99") and Adobe Commerce returns a number (for example 19.99). Compare like for like or you will rewrite prices that did not actually change.
Adobe Commerce update-product rejects a quoted price. Pass price as a raw number in the product object.
Set the schedule timezone explicitly. A cron expression with no timezone, or the wrong one, fires at an unexpected hour and can clash with other store jobs.
Do not run a reverse sync at the same time. This workflow treats Shopify as the source of truth; a second workflow pushing Adobe Commerce prices back to Shopify would create a loop.

Testing

Before turning the schedule on, validate against a single product. Temporarily tighten the Shopify query to one SKU (for example sku:TEST-001), change that product's price in Shopify, then use the Run button to fire a manual pass. Open the run in your execution history and confirm the Condition node took the true branch and that update-product wrote the expected price to Adobe Commerce. Verify the new price in the Adobe Commerce admin, then run again with no price change and confirm the workflow takes the false branch and performs zero writes. Once both cases behave, widen the query back to your full catalog and enable the schedule. If anything looks off, ask Miraxa, the intelligent layer across your automation, why the last run skipped or updated a product.