Many merchants eventually run more than one Shopify store. The stores may represent regions, brands, wholesale and retail channels, or a staging store used for testing.
Inventory is often the first pain point. One store receives stock changes, but another store needs the same availability. If the sync is manual, stock can drift quickly.
The pain point
Multi-store inventory sync is not just "copy this number."
The workflow may need to:
- Read inventory from a source store.
- Match products or variants by SKU.
- Map one store's location to another store's location.
- Ignore SKUs that should not sync.
- Handle variants that exist in one store but not the other.
- Update available inventory safely.
- Retry Shopify throttling or transient API failures.
- Send a summary of updated, skipped, and failed records.
This is operational work that needs clear logs and guardrails.
Why a custom Shopify app connection helps
For the store where JsWorkflows is installed, the built-in Shopify access is usually enough. For another store, the workflow needs a separate Shopify connection.
That can be handled with a Shopify custom app connection. The workflow can load the OAuth token for the secondary store and call that store's Admin API when needed.
The detailed setup is covered in the Shopify Custom App OAuth guide.
A practical workflow shape
A multi-store inventory workflow can run on a schedule or after an inventory event.
One safe pattern is:
- Load the source store's inventory state.
- Build a list of SKUs and location quantities.
- Load matching variants or inventory items in the target store.
- Prepare updates only for confident matches.
- Apply updates in batches.
- Log missing SKUs and skipped rows.
- Send a summary email or Slack message.
The workflow should avoid silent failure. If a SKU cannot be matched, the workflow should report it instead of guessing.
Where JsWorkflows fits
No-code automation can be useful for single-store event rules. Multi-store sync usually needs a few extra capabilities:
- Multiple Shopify Admin API calls.
- A separate token for the second store.
- SKU matching and location mapping logic.
- Batching and retries.
- A clear run history.
JsWorkflows is a good fit because the workflow can keep merchant-facing values configurable while the code handles the API mechanics.
Merchant-facing settings might include:
- Source store handle.
- Target store domain.
- Location mappings.
- Included or excluded SKUs.
- Notification email.
Technical details such as page size, batch size, retry count, and throttle handling should stay in code.
Use cases
This pattern can support:
- Regional stores that share a catalog.
- Wholesale and retail stores with shared stock.
- Testing inventory workflows on a development store.
- Migration jobs from an old store to a new store.
- Selective sync for a subset of SKUs or vendors.
What to avoid
Do not start with automatic updates across every SKU and every location.
Start with a narrow scope. Sync one location, one product type, or one SKU prefix. Review the logs, confirm the matches, then expand.
Inventory mistakes affect sales immediately. A controlled workflow should make it easy to see what changed and why.