How to Send Appointment and Booking Reminders for In-Store Services

Build a Spojit workflow that runs every afternoon, pulls tomorrow's in-store service bookings from your booking platform's REST API, and emails each customer a friendly day-ahead reminder with only their name, the service, and the time.

What This Integration Does

Retail pharmacies and health-retail stores run plenty of booked in-store services: vaccination clinics, wellness consults, device fittings, and similar slots. No-shows waste staff time and the customer's appointment. This workflow sends a single, polite reminder the day before, so the customer can confirm or rebook. It is framed strictly as a scheduling reminder: it carries the customer's name, the service name, and the appointment time, and nothing clinical. There are no diagnoses, no treatment notes, and no medical record content anywhere in the message.

A Schedule trigger fires once each afternoon in your store's timezone. A Connector node on the http connector calls your booking platform's REST API with http-get to retrieve tomorrow's slots. A Transform node and the date connector localize each time into a readable label, a Loop node iterates the bookings, and a Send Email node delivers one reminder per booking. Each run is independent and reads only that day's lookahead, so re-running it simply re-sends the same set of reminders. To avoid duplicate sends, run the schedule once per day and keep its window narrow.

Prerequisites

A booking platform that exposes a REST API returning tomorrow's bookings (customer name, service name, start time). Most scheduling tools have one. Spojit reaches it through the built-in http connector, so no native tile is required.
An API key or token for that booking platform, plus the exact endpoint URL and query parameters for a date range.
Customer email addresses present in the booking records. If your platform omits them, add a lookup step against your CRM's REST API via the http connector.
Your store's IANA timezone (for example Australia/Sydney or America/New_York).
If you send from your own domain instead of Spojit's built-in mail service, a configured Resend connection. Otherwise the Send Email node needs each recipient domain on your org allowlist under Settings > General > Email recipients.

Step 1: Add a Schedule trigger for the afternoon run

Create a new workflow and set the trigger type to Schedule. Add a 5-field cron expression and your store's IANA timezone. To run every day at 3:00 PM local time, use:

0 15 * * *
Australia/Sydney

The trigger output is {{ scheduledAt }}, the moment the run started. You will use this to compute "tomorrow". A single trigger can hold multiple schedules if you run several stores in different timezones.

Step 2: Compute tomorrow's date range with the date connector

Add a Connector node on the date connector in Direct mode and pick the add tool to advance one day from the run time. Pass {{ scheduledAt }} as the date and add 1 day. Then add a second date Connector node using format with the token YYYY-MM-DD and your store timezone to produce a clean date string, for example 2026-06-22. Store it as a variable such as {{ targetDate }}. Direct mode is deterministic and uses no AI credits, which is what you want for a date calculation.

Step 3: Fetch tomorrow's bookings from your booking platform's REST API

Add a Connector node on the http connector in Direct mode and choose http-get. Point it at your booking platform's REST endpoint and pass {{ targetDate }} as the date filter. Put your API key in the Authorization header. A typical request looks like:

GET https://api.yourbookingplatform.com/v1/appointments?date={{ targetDate }}&status=confirmed

Headers:
  Authorization: Bearer YOUR_API_KEY
  Accept: application/json

Map the response to a variable such as {{ bookingsResponse }}. This is the same honest http connector pattern Spojit uses for any system without a native tile, covered in How to Connect to Any REST API Using HTTP Requests.

Step 4: Shape the bookings into a clean list with the json and Transform nodes

Booking APIs nest the records differently. Add a Connector node on the json connector in Direct mode and use get or query to pull the array of bookings out of the response, for example a path like data.appointments, into {{ bookings }}. Then add a Transform node to reduce each record to only the three fields you will send: customer name, service name, and start time. Keep the shape minimal so nothing clinical travels downstream:

{
  "customerName": "{{ item.customer.name }}",
  "serviceName": "{{ item.service.title }}",
  "startTime": "{{ item.start }}",
  "email": "{{ item.customer.email }}"
}

Step 5: Loop over the bookings and localize each time

Add a Loop node in ForEach mode over {{ bookings }}. Inside the loop, add a Connector node on the date connector in Direct mode using the format tool to turn the raw startTime into a human-friendly label. Pass {{ item.startTime }} as the date, your store timezone, and a readable token:

date:    {{ item.startTime }}
format:  dddd D MMM, h:mm A
timezone: Australia/Sydney

This yields something like Monday 22 Jun, 2:30 PM. Store it as {{ slotLabel }} for the email body. Formatting per booking keeps each customer's local time correct even if records span timezones.

Step 6: Send one reminder per booking with the Send Email node

Still inside the Loop, add a Send Email node. Set Recipients to {{ item.email }}, write a short subject, and keep the body limited to the name, service, and time:

Subject: Reminder: your {{ item.serviceName }} booking tomorrow

Hi {{ item.customerName }},

This is a friendly reminder of your booking at our store:

  Service: {{ item.serviceName }}
  When:    {{ slotLabel }}

If you need to reschedule, just reply to this email or give us a call.

See you then!

Set If sending fails to Continue anyway so one bad address does not stop the rest of the reminders. To send from your own branded domain instead of Spojit's built-in mail service, swap this for a Connector node on the resend connector in Direct mode using send-email, as shown in How to Build Email Notifications with Resend.

Tips

Keep the reminder content to name, service, and time only. Do not include any clinical detail, notes, or reason-for-visit fields even if the API returns them. Drop those columns in the Transform node in Step 4.
If your platform paginates, request a generous page size or loop pages in the http-get step. A single afternoon of bookings is usually small enough to fetch in one call.
Use Miraxa, the intelligent layer across your automation, to scaffold this fast. Try a prompt like: "Add a Loop node over {{ bookings }} with a date format step and a Send Email node inside it." Then fine-tune the fields in the properties panel.
If you run several stores, give each its own Schedule entry with the right timezone, or pass a store ID into the http-get query so one workflow covers them all.

Common Pitfalls

Timezone drift. Compute "tomorrow" and format slot times in the same store timezone you set on the Schedule trigger. Mixing the run timezone with a UTC API value sends reminders for the wrong day.
Missing email addresses. If a booking has no email, the Send Email node cannot deliver. Add a Condition node inside the loop to skip records where {{ item.email }} is empty, or enrich them from your CRM's REST API via the http connector first.
Recipient allowlist. The built-in Send Email service only delivers to domains on your org allowlist. For customer mail at scale, switch to the resend connector with a verified domain.
Duplicate sends. Each run re-reads the same lookahead window, so re-running the workflow re-sends reminders. Schedule it once per day and avoid manual re-runs unless you intend to resend.

Testing

Before turning the schedule on, validate on a tiny scope. Temporarily point the http-get step at a test query that returns one or two of your own bookings, or hard-code {{ targetDate }} to a day you control. Use the Run button to execute once, then open the run in the execution history and confirm the http step returned the expected records, the date format step produced a readable local time, and the Send Email step addressed the right recipient with only name, service, and time. Once a single reminder looks right, restore the live query and enable the Schedule trigger.