How to Automate Supplier Reordering for Low Front-of-Store Stock

Build a Spojit workflow that checks front-of-store retail stock every morning, drafts a supplier purchase order for any item below its reorder point, pauses for a buyer to approve, and only then posts each line to your supplier's REST API.

What This Integration Does

Front-of-store retail lines, the over-the-counter and general merchandise stock that sits on your shelves, run out quietly between manual counts. This workflow watches those quantities for you. Each morning it reads current counts, picks out everything that has dropped below the reorder point you set, and assembles a draft purchase order. A buyer reviews that draft in Spojit and approves or rejects it, so nothing is ordered automatically without a human signing off. On approval, the workflow sends each line to your supplier's ordering API and posts a confirmation to Slack. This is purely retail procurement: stock levels, reorder points, and supplier line items, with no clinical context.

A Schedule trigger starts the run on a cron you control (for example weekday mornings). A Connector node on the shopify connector reads inventory (or your point-of-sale system via the http connector), a Condition node filters to the items that need reordering, a Human node pauses for buyer sign-off, and on approval a Loop node posts one order line at a time to your supplier with http-post. A Connector node on slack confirms what was ordered. Each run leaves a draft, then either an approved order plus a Slack message, or a halted run if the buyer rejects. Re-runs are independent: the workflow re-reads live counts each morning, so an item that was restocked overnight simply will not appear in the next draft.

Prerequisites

A shopify connection (API key) if your front-of-store catalog lives in Shopify, with read access to products and inventory. If your stock lives in a point-of-sale or back-office system instead, you need that system's REST API base URL and an API key for the http connector.
Your supplier's ordering REST API: base URL, the create-order endpoint path, and an API key or token for the Authorization header.
A slack connection with access to the channel where you want order confirmations posted.
A reorder map: for each product you track, an item identifier, a reorder point (the count at which you reorder), and a reorder quantity. Keep this somewhere the workflow can read (a small JSON list works well).
At least one buyer set up as a Spojit user, role, or team to act as an approver.

Step 1: Start the workflow on a morning Schedule trigger

Add a Trigger node and set its type to Schedule. Enter a 5-field cron expression and an IANA timezone so it fires at the same local time every working day. For example, run at 6 AM on weekdays:

Cron:     0 6 * * 1-5
Timezone: Australia/Sydney

The Schedule trigger outputs { scheduledAt }, which you do not need downstream here; it just kicks off the run. A single trigger can hold multiple schedules if you want a second check later in the day.

Step 2: Read current front-of-store stock

Add a Connector node in Direct mode on the shopify connector and select the list-products tool to pull the catalog you track. Use the query field to narrow it, for example status:active, and set first up to 250 per page. For each product you care about, follow with a Connector node on shopify using get-inventory-levels, passing the inventoryItemId to get the on-hand quantity across locations.

If your front-of-store stock lives in a point-of-sale or back-office system that Spojit has no native tile for, read it with the http connector instead. Add a Connector node in Direct mode on http, choose http-get, and call your system's inventory endpoint:

Method: GET
URL:    https://api.yourpos.example.com/v1/inventory?location=front-store
Headers:
  Authorization: Bearer {{ secrets.posApiKey }}
  Accept: application/json

Either way, the goal of this step is a list of items each carrying an identifier and a current count. See the cross-link in Learn More for the full HTTP technique.

Step 3: Build the reorder list with a Transform node

Add a Transform node to reshape the raw stock response into a clean array your Condition can evaluate. Merge each item's live count with its reorder point and reorder quantity from your reorder map, producing one object per product. Aim for a shape like this so later steps can reference fields directly:

[
  { "sku": "OTC-LOZENGE-50", "supplierId": "SUP-1042", "onHand": 4, "reorderPoint": 12, "reorderQty": 48 },
  { "sku": "GM-TISSUE-3PK",   "supplierId": "SUP-2210", "onHand": 30, "reorderPoint": 10, "reorderQty": 24 }
]

If your reorder map is a JSON list, you can use the json connector (for example parse to read it and merge or pick to combine fields) before or inside this Transform. The result is bound to a variable such as {{ stockItems }}.

Step 4: Select items below their reorder point with a Condition node

Add a Condition node to keep only the lines that actually need ordering. Evaluate each item so the true branch carries items where on-hand has dropped to or below the reorder point, for example {{ item.onHand }} is less than or equal to {{ item.reorderPoint }}. Route the false branch to the end of the workflow so a morning with nothing low simply finishes quietly.

If you prefer to filter the whole array in one place rather than branch item by item, the array connector filter tool can return only the below-threshold items into a variable such as {{ reorderLines }}. Use whichever reads more clearly for your team; the Condition keeps the branch logic visible on the canvas.

Step 5: Pause for a buyer to approve the draft order

Add a Human node so nothing reaches your supplier without sign-off. Give it a clear Label like Approve supplier reorder and a Message that summarizes the draft, using upstream variables so the approver sees exactly what is about to be ordered:

Reorder draft for {{ date.today }}:
{{ reorderLines.length }} line(s) below reorder point.
Approve to send these to suppliers, or reject to cancel.

Set a Timeout (minutes) if you want the draft to lapse when no one responds (a timeout is treated as a reject and halts the run). Set Urgency to Normal or High, optionally turn on Email approvers, and fill the Approval slots with the buyer user, a Buyer role, or a Purchasing team. Approval completes only when every slot is satisfied. On approval the node outputs { approved: true, approvalId, outcome: "APPROVED" } and the run continues. A reject halts the run, so place nothing critical on a "rejected" path: there is no reject branch.

Step 6: Loop the approved lines to your supplier's API

Add a Loop node in ForEach mode over {{ reorderLines }}. Inside the loop body, add a Connector node in Direct mode on the http connector and select http-post to create one purchase order line at your supplier's REST API:

Method: POST
URL:    https://api.yoursupplier.example.com/v1/purchase-orders
Headers:
  Authorization: Bearer {{ secrets.supplierApiKey }}
  Content-Type: application/json
Body:
  {
    "supplier": "{{ item.supplierId }}",
    "sku": "{{ item.sku }}",
    "quantity": {{ item.reorderQty }},
    "reference": "auto-reorder-{{ scheduledAt }}"
  }

Collect each response (for example the supplier's order or line ID) into a result variable so you can report on it after the loop. If you would rather submit one combined order, post the full array in a single http-post outside a loop instead; the per-line loop keeps each line independently retryable.

Step 7: Confirm what was ordered in Slack

After the loop, add a Connector node in Direct mode on the slack connector and select send-message. Set the target channel and build a text summary from the loop results so the team sees exactly what went out:

Channel: #store-procurement
Text:    Supplier reorder approved and sent ({{ reorderLines.length }} lines).
         {{ orderSummary }}

You can ask Miraxa, the intelligent layer across your automation, to scaffold any of these steps from a sentence (for example "Add a Loop over {{ reorderLines }} with an http-post Connector node inside"), then fine-tune the fields in the properties panel.

Tips

Keep reorder points and quantities in one editable JSON list (or a small reference your workflow reads) rather than hard-coding them in nodes, so buyers can adjust thresholds without touching the canvas.
Add the draft summary to the Human node Notification title/body as well as the Message, so approvers see the key numbers in the notification before opening the Approvals inbox.
If your supplier API rate-limits, leave the Loop in ForEach mode (one request at a time) rather than fanning out with a Parallel node, and check the supplier's per-minute limits.
Use a stable reference value (built from the run, as above) on each supplier line so duplicate runs are easy to spot and reconcile on the supplier side.

Common Pitfalls

Shopify list-products returns paginated results (up to 250 per page). If your catalog is larger, page through using the cursor so you do not silently miss low-stock items.
A rejected or timed-out Human node halts the run with no downstream branch. If you want a record of cancelled drafts, capture it before the Human node or send the draft to Slack ahead of approval, not after a reject.
Match your Schedule timezone to the store's local time. A cron set in the wrong IANA zone can fire after the morning delivery window instead of before it.
Confirm the supplier API expects the exact field names and types you send in the http-post body. A wrong key or a quoted number where a numeric is expected will be rejected per line, so validate the payload against their docs first.

Testing

Validate on a small scope before enabling the schedule. Temporarily point the workflow at a handful of test items with reorder points set so exactly one or two fall below, and aim the http-post at your supplier's sandbox or test endpoint. Use the Run button to execute on demand instead of waiting for the cron. Step through the execution log: confirm the Condition selects the right lines, the Human node pauses and shows the correct draft in /approvals, and that approving it posts only the expected lines and Slack confirms them. Once a single approve-and-send cycle behaves correctly, widen the item set and turn the Schedule trigger on.