How to Send Refill Reminders to Repeat Retail Customers

Build a Spojit workflow that runs every morning, looks up customers whose recurring purchase is due, and emails each one a gentle, branded reminder to reorder.

What This Integration Does

Many retail and pharmacy customers buy the same item on a predictable cycle: a 30-day supply, a monthly top-up, a recurring household staple. When that cycle date arrives, a short reminder to come back and reorder is one of the most reliable ways to keep repeat customers buying. This workflow automates that nudge end to end so your team never has to scan a spreadsheet of reorder dates by hand. It reads the cycle dates already held in your own pharmacy or retail system, figures out who is reaching their reorder window today, and sends each of those customers a friendly note from your own domain.

The reminder is strictly a reorder prompt. It carries only the customer's first name and a generic line inviting them to refill or reorder. It never includes clinical content, product specifics that imply a condition, or anything beyond a retail nudge. The workflow is triggered on a daily Schedule, calls your system's REST API through the http connector to pull the list of upcoming cycle dates, uses the date and json connectors to decide who is due, loops over the matching customers, and sends each email with the resend connector. It writes nothing back to your system, so re-runs are safe: if you run it twice in a day, the same customers simply receive at most one reminder per scheduled run, and you control duplicates with the date window described below.

Prerequisites

An http connection (or the customer's API key ready to pass in a header) for the pharmacy or retail system that stores your customer reorder cycle dates. The http connector is built in and needs no separate sign-in, but you will need the system's base URL and a valid API key.
A resend connection with a verified sending domain, so reminders go out from your own address. See the Resend connector reference and the email notifications tutorial.
A field in your system you can query that holds, for each customer, a nextReorderDate (or equivalent cycle date), a first name, and an email address.
The json and date utility connectors, which are built in and require no connection.

Step 1: Start the workflow on a daily Schedule trigger

Add a Trigger node and set its type to Schedule. A Schedule trigger uses a 5-field Unix cron expression plus an IANA timezone. To run once every weekday morning at 9:00, use:

0 9 * * 1-5

Set the timezone to your store's local zone, for example Australia/Sydney, so the run fires at 9am local time regardless of server location. Each run produces an output of { scheduledAt }, which you can reference downstream as {{ trigger.scheduledAt }} when you compute the reorder window. If you want the reminder to land seven days before items run out, you will offset from this date in Step 3.

Step 2: Pull due reorder records with a Connector node on http

Add a Connector node, choose the http connector, and set it to Direct mode so the call is deterministic and costs no AI credits. Pick the http-get tool. Point it at your system's REST endpoint that lists customers with upcoming cycle dates, and pass your API key in the request header. For example, set the URL to your system's list endpoint and add a header:

GET https://api.yourpharmacysystem.com/v1/customers?dueWithinDays=10

Authorization: Bearer YOUR_API_KEY
Accept: application/json

If your system has no native Spojit tile, this is the intended pattern: reach it honestly through the http connector rather than expecting a named connector. For a fuller walkthrough of authenticating and shaping these calls, see connecting to any REST API. Store the result in a variable such as dueCustomers so later steps can read {{ dueCustomers.body }}.

Step 3: Compute the reorder window date with the date connector

Add a second Connector node on the date connector in Direct mode. For each customer you want to know how many days remain until their cycle date, so you can select only those reaching the reorder window. Use the diff tool, which takes date1 and date2 and returns a numeric value in the requested unit. Compare the customer's stored cycle date against today's scheduled date:

{
  "date1": "{{ customer.nextReorderDate }}",
  "date2": "{{ trigger.scheduledAt }}",
  "unit": "day"
}

The tool returns { value, unit }, where a value of 7 means the customer is seven days out from their reorder date. You will run this per customer inside the Loop in Step 5, then branch on the result in the Condition node. If your http-get in Step 2 already filtered to a narrow window (for example dueWithinDays=10), this step gives you the precise per-customer number to gate on.

Step 4: Normalize the customer list with the json connector

Before looping, make sure you are iterating over a clean array. Add a Connector node on the json connector in Direct mode. If your API nests the records under a wrapper key, use the get tool to pull out just the list, for example reading the customers path from {{ dueCustomers.body }}. If you only need a few fields per customer, the pick tool trims each record down to firstName, email, and nextReorderDate, which keeps later steps tidy and avoids passing extra data around. Store the cleaned array in a variable such as customers.

Step 5: Loop over each due customer

Add a Loop node in ForEach mode and point it at {{ customers }}. Inside the loop body, each iteration exposes the current record (for example as {{ customer }}). This is where you place the per-customer date diff from Step 3, the Condition node from Step 6, and the Send Email step. Keeping the diff inside the loop means each customer is evaluated against their own cycle date. For guidance on iteration modes and referencing the current item, see using Loop nodes.

Step 6: Select customers in the reorder window with a Condition node

Inside the loop, add a Condition node that checks the day count returned by the diff tool. To remind customers exactly seven days before their cycle date, branch on:

{{ dateDiff.value }} == 7

Send the true branch to the Send Email step in Step 7. Leave the false branch empty so customers who are not yet at the window are simply skipped this run. Matching on a single exact day (rather than "less than or equal to seven") is what keeps re-runs safe: a given customer only satisfies the condition on one calendar day, so a daily schedule sends at most one reminder per cycle. See using Condition nodes for expression syntax.

Step 7: Send the branded reminder with resend send-email

On the Condition node's true branch, add a Connector node on the resend connector in Direct mode and choose the send-email tool. Map the fields to the current customer and keep the copy to a plain reorder prompt with no clinical content:

{
  "from": "Your Pharmacy ",
  "to": "{{ customer.email }}",
  "subject": "Time to reorder, {{ customer.firstName }}?",
  "text": "Hi {{ customer.firstName }},\n\nThis is a friendly reminder that one of your regular items is due for a refill soon. Pop in or reply to this email when you would like to reorder, and we will have it ready for you.\n\nThanks,\nYour Pharmacy team",
  "reply_to": "hello@yourdomain.com"
}

Because send-email goes out through your verified resend domain, the message arrives from your own address rather than a generic Spojit sender. If you would rather not manage a sending domain, you can swap this step for a built-in Send Email node, though external recipients must then be on your org allowlist. Keep the subject and body to the name plus a generic refill prompt only: do not mention specific medications, conditions, or any clinical detail.

Tips

Use Direct mode on every Connector node here. The logic is fully deterministic, so you avoid AI credit cost and get repeatable runs.
If your system paginates results, loop your http-get call over pages, or narrow the query with a dueWithinDays filter so each run returns a small, predictable batch.
To remind at multiple lead times (for example seven days out and again on the day), add a second Condition branch checking {{ dateDiff.value }} == 0 and a second Send Email step with day-of copy.
Scaffold the structure quickly by asking Miraxa, the intelligent layer across your automation, something like: "Add a Loop over {{ customers }} with a Condition that checks if {{ dateDiff.value }} is 7 and connect the true branch to a resend send-email step." Then fine-tune fields in the properties panel.

Common Pitfalls

Timezone drift. The Schedule trigger's timezone and the format of nextReorderDate must agree. If your dates are stored as plain calendar dates, the diff in days can be off by one across midnight. Set the schedule to a fixed local zone and compare whole days.
Wrong window operator. Using <= 7 instead of == 7 makes a customer match on every day inside the window, so they get a reminder daily. Match a single exact day to keep one reminder per cycle.
Unverified sending domain. The send-email call fails if your resend domain is not verified, or if from uses an address outside that domain. Verify the domain first and use a from on it.
Over-sharing content. Pulling extra fields from your system and dropping them into the email risks leaking clinical or product detail. Use the json pick tool to expose only name, email, and date to the email step.

Testing

Before turning the schedule on, validate on a tiny scope. Temporarily point your http-get at a test query that returns one or two known records, or set dueWithinDays so only a single customer matches. Use the workflow's Run button to fire it once on demand, then open the execution log to confirm the Connector node returned the expected list, the diff value is what you expect, the Condition branched correctly, and the send-email step reported success. Send the first live reminders to an internal mailbox you control by overriding to, read the wording end to end to confirm it carries only name plus a generic refill prompt, then switch to back to {{ customer.email }} and enable the Schedule.