Stocky Shut Down: How to Rebuild Shopify Reorder Alerts With Make

Automate My Life

·

Builder · Level 2 of 3

Stocky is no longer available as of August 31, 2026. If your restocking routine depended on it, start by checking what Shopify now provides. You can manage purchase orders in Shopify admin, and Shopify Flow has low-stock notification templates. Use Make when your alert needs an external threshold sheet, a custom destination, or another app in the same workflow. The design below keeps the decision to place an order with you.

Check the built-in options before adding Make

Shopify’s migration guide covers the move from Stocky to native inventory management, including purchase orders and supplier workflows. It also describes read-only export access for at least 90 days after August 31. Stocky’s APIs stopped on that date; they are not the connection to use for this build.

For a straightforward warning email, try Shopify Flow’s inventory-change trigger and low-stock templates first. The trigger provides the product, variant, and prior inventory quantity; Shopify also documents how to select a location’s available quantity. Make is useful when you need your own lookup table or destination. It is not required just because Stocky closed.

What this design does

The workflow takes one inventory change, identifies the inventory item and location, looks up your threshold, checks current availability, and writes a restocking reminder. It does not create a purchase order, change inventory, or claim to replace demand forecasting. You can review a reminder and then use Shopify’s native purchase-order workflow.

Evidence and testing: Documentation checked October 30, 2026. This is a desk-reviewed design, not a scenario built or run against a live Shopify store. Confirm the trigger topic, returned fields, permissions, and credit usage in your own accounts before enabling production alerts. Worked quantities below are examples, not measured results.

Prepare one test item and a small threshold table

  • Use a paid Shopify account and an authorized Make connection; these are requirements in Make’s Shopify documentation. Prefer its standard connection unless you have a specific custom-app need.
  • Choose one tracked inventory item at one location. Record its stable inventory-item ID, location ID, SKU, and current available quantity. A SKU alone may be empty, duplicated, or shared across locations.
  • Create a threshold table with inventory_item_id, location_id, reorder_threshold, target_stock, and enabled columns. Add a separate alert-state record keyed by the item/location pair.
  • Pick a reminder destination that you can inspect during testing. Authenticate that email, sheet, or chat connection separately; do not assume it comes with your Shopify connection.

Step 1: Receive and identify an inventory change

  1. Create a Make scenario and add Shopify’s Watch events (advanced) trigger. Make lists that trigger in its current app documentation. In your account, confirm that it exposes an inventory-level update topic for the connection you authorized. If it does not, stop and use a supported alternative rather than substituting a product-change trigger without testing it.
  2. Change the quantity of your test item and inspect the received bundle. Map the actual inventory-item ID, location ID, available quantity, and any event identifier returned by that topic. Do not assume it contains a SKU or a product-variant ID.
  3. If the bundle lacks the human-readable product information you need, resolve the inventory item to its variant using an authorized supported lookup. Check that the returned inventory-item ID matches your input before using the SKU.
  4. Look up the enabled threshold row by item ID plus location ID. Skip missing or ambiguous rows into a review log. Keep the skip branch free of inventory writes and supplier emails.

Step 2: Check the threshold without sending repeated alerts

A filter such as available <= reorder_threshold is a low-stock check, not a crossing detector. With a threshold of 10, changes from 9 to 8 and 8 to 7 both satisfy it. Without state, both can send another message.

  1. Use the item/location key to read the last alert state. Before deciding, fetch current availability through the supported connection if the webhook may be stale. Keep the latest observed event/time so an older delivery cannot overwrite newer state.
  2. If current availability is above the threshold, record the recovered state and rearm the next low-stock warning. If it is low and no warning is outstanding, create a pending alert record for that low-stock episode.
  3. Process this state-changing path sequentially or use an atomic reservation in your chosen store. A separate read followed by a write can race. Record the delivery result against the reservation.
  4. If a message request times out, retain its pending state and check the destination before retrying. Do not reset the reservation and send again just because the response was lost. Keep an exception list for unresolved deliveries.

Include the item, location, current availability, threshold, and a link to the record you review. Keep supplier orders and inventory adjustments outside this scenario until you have separately designed and tested their approval and duplicate controls.

Optional: suggest a quantity for human review

For a simple target-stock rule, use max(0, target_stock − available − confirmed_incoming). If your example target is 40 units, availability is 8, and 12 confirmed units are incoming, the suggestion is 20. If incoming stock is unknown, mark the suggestion incomplete instead of treating it as zero. Demand, lead times, pack sizes, and seasonality require additional decisions. This arithmetic is an editorial example, not a forecasting result.

Test the failures as well as the happy path

  • Above threshold: no message. First low observation: one reminder. Another lower observation: no duplicate for the same episode. Recovery above threshold followed by another low observation: a new reminder.
  • Deliver the same sample twice and then deliver an older sample after a newer one. Check that neither produces a duplicate or reverses current state.
  • Try a missing threshold, duplicate lookup row, disabled item, empty SKU, and second location. Each should produce the explicit skip or review outcome you designed.
  • Disconnect the destination, exhaust a test allowance, or simulate an uncertain delivery using a safe test endpoint. Check that failures remain visible and do not silently become delivered.
  • Compare the reminder with Shopify’s actual current quantity. Keep a manual inventory check available while you establish that the workflow behaves correctly.

Budget for the path you actually run

Make bills in credits; its Free plan lists 1,000 monthly credits. Paid prices depend on the selected allowance and billing term, so check the current quote instead of choosing Core or Pro from an old price table. Measure lookup, state, delivery, and retry usage during your own test. There is no documented basis here for promising that a particular paid tier has enough headroom for your store.

For planning only, 1,000 eligible changes times an assumed five credits per completed path is 5,000 credits before retries and other scenarios. Replace that assumption with observed usage. Supplier orders, transferred customer data, and a second storage service can add costs or privacy obligations beyond the Make subscription.

When to use something else

Stay with Shopify Flow if its built-in notification meets the need. Choose dedicated planning software when you need tested forecasting, many locations, supplier lead-time rules, or a maintained purchasing process. A spreadsheet and a custom alert can become another system you have to keep accurate. Review access permissions, missing-threshold logs, pending deliveries, and sampled stock counts regularly.

For Make’s interface and scenario basics, see Make.com for Beginners. The automation-tool shutdown checklist helps you plan a fallback, and Zapier vs Make vs n8n compares the broader platform choices.