Skip to content
Use cases & recipes
4 min read

Appointment reminders

Remind people about a booking and handle the reply when they need to reschedule.

Share article

This recipe sends a reminder before an appointment and handles the reply when someone needs to change it. It is a good first workflow because it exercises contacts, sends, idempotency and webhooks in one small flow.

Prerequisites

  • An active account with a messaging service.
  • An API client with read and write access.
  • A way to receive webhooks — a public HTTPS endpoint you control.
  • Appointment records that carry a phone number and a stable identifier.

The flow

  1. Create or update the contact for the person with the appointment.
  2. Send the reminder, keyed on the appointment id.
  3. Subscribe to delivery and inbound events so you know what happened.
  4. When the person replies, read the message and act on it.

Step 1 — make sure the contact exists

Contacts are identified by phone number. If you already have the contact, a sync merges the fields you send and leaves the rest alone.

{
  "phone": "+15555550100",
  "firstName": "Alex",
  "lastName": "Morgan",
  "language": "en",
  "note": "Appointment 4821"
}
A sync creates the contact if it is new and merges it if it already exists.

Step 2 — send the reminder

Send the reminder to the contact. Use an idempotency key derived from the appointment so that a retry — yours or the network's — does not produce a second reminder.

request.json
{
  "recipients": ["+15555550100"],
  "body": "Hi Alex, this is a reminder of your appointment tomorrow at 10:00. Reply C to confirm or R to reschedule.",
  "type": "sms"
}
Idempotency-Key: appt-4821-reminder-24h
Any stable 16–128 character value works. Derive it from the appointment, not from the clock.

Step 3 — listen for what happened

A successful send means Furcata accepted the message. It does not mean the message arrived. Subscribe to the delivery, failure and inbound events and treat those as your source of truth.

{
  "target_url": "https://example.com/hooks/furcata",
  "event": "message.delivered"
}
Subscribe once per event type you care about.

Step 4 — handle the reply

When the inbound event fires, read the body and route it. A short keyword is easier to act on than free text, so tell people what to reply in the reminder itself.

  • A confirmation needs no further action — mark the appointment confirmed.
  • A reschedule request should reach a human, or trigger your own rescheduling flow.
  • Anything you do not recognise should still be stored; a person will want to read it.

Do not remind twice

The most common defect in this recipe is a duplicate reminder caused by a retry without an idempotency key. Generate the key once per appointment and per reminder window, and store it.

Variations

Remind more than once

For a second reminder, use a different key — for example the same appointment id with a different window suffix. Two reminders should be two logical sends.

Send from a different number

If you run several services, keep the reminder on the number the person already associates with you, so the message is recognisable.

Escalate to a call

For appointments where no answer would be costly, a voice message is a stronger nudge than a text. Voice is configured in the app rather than through the REST API.

Next recipe

Order and delivery updates take the same building blocks and add an event source from your store.

Order and delivery updates