WhatsApp Business for medical practices: app, API and bookings

WhatsApp Business can organize a medical practice's administrative communication: opening hours, appointment requests, confirmations and changes. Automating those workflows requires choosing between the app and the official platform, deciding how scheduling connects and checking which messages may be sent. Clinical care and medical decisions remain with the healthcare team.

Imagine someone asks about availability after reception closes. An automated reply can provide guidance; a booking exists only when the scheduling system confirms the slot. Keeping those events distinct prevents the chat from promising an appointment nobody recorded. This guide covers implementation decisions; see our medical-practice AI agent guide for the broader service.

1 · WhatsApp Business app or API: what does your practice need?

The API itself does not supply a calendar, team inbox or ready-made assistant. Those components must be built or contracted. If reception handles the current volume well, organizing the app and a booking link may be a sufficient first step.

Do you need to change your number or delete the app?

Check the onboarding route first. Coexistence routes can let eligible businesses use the app and a platform integration on the same number, depending on the provider. Other routes require migration. Do not delete accounts or disconnect the number before checking history, access and continuity. HubSpot documents its own coexistence implementation; its limitations do not describe every provider.

2 · Design administrative communication around minimal data

Colombia's Law 1581 of 2012, articles 5 and 6, classifies health data as sensitive and sets special conditions for processing it. Even an appointment can reveal sensitive information: calling a message administrative does not remove the risk.

• Request only what is needed: the service, availability and a contact for booking. Avoid routinely collecting identity documents or symptoms.
• Limit access and retention: define who can read chats, where information is held, retention and how data-subject requests are handled.
• Define authorization and purpose: record the applicable basis and contact preferences; a reminder does not amount to permission for promotional campaigns.
• Separate clinical care: the assistant does not diagnose, prescribe or assign medical urgency. Refer clinical questions to the provider's designated channels; emergency care must not depend on an AI classification.

Review channel policies together with the practice's obligations. This is operational guidance; installing an API or agent does not certify legal compliance. The WhatsApp Business policy also sets responsibilities for permissions, information and human escalation. This article uses Colombia as its legal context; requirements elsewhere need a local assessment.

3 · Number onboarding, business checks and permissions are separate

Prepare the practice's details, number ownership and access, administrators and implementation route. Any business verification Meta requests, number registration, app-permission review for third-party operation and template approval are distinct processes. Not every implementation needs the same path.

Check actual account states before agreeing on activation. A proposal can schedule MD's work once inputs and access are available; it cannot control Meta's decisions. Our WhatsApp API approval guide separates the steps and tests. The preparation checklist helps organize the inputs.

4 · The 24-hour window determines message format

On the platform, each user message opens or resets a 24-hour customer-service window. Inside it, replies can be sent without a template; outside it, an approved template is required. Time is counted from the last user message, not the practice's last reply. See WhatsApp's published rule.

A reminder is not automatically a free-form message or a template just because it is a reminder: check the window and purpose. Template approval does not authorize arbitrary content or replace contact preferences.

A timing example without patient data

1. The person writes on Monday at 10:00. The window is counted from that message.
2. Reception replies and records the booking; its reply does not restart the clock.
3. If no further user message arrives, sending after 10:00 on Tuesday requires an approved template.
4. When the person replies, a new window opens for the conversation.

5 · Three templates to prepare and test

The following are illustrative drafts. They need adaptation, a category and variable examples in Meta; approval is not guaranteed.

Confirmation: “Your appointment is recorded for {{date}} at {{time}}. To change it, reply to this message or contact reception.”

Reminder: “A reminder of your appointment on {{date}} at {{time}}. You can confirm, request a change or cancel through this channel.”

Requested change: “We received your change request. Reception will confirm new availability.” Do not describe a request as an accepted booking.

Keep diagnoses, results, procedures and individualized clinical instructions out of sample texts and notifications. Check what may appear on a locked screen. Adding a promotion to a reminder changes its purpose and needs separate assessment.

6 · From chat to a confirmed appointment

1. Guide: identify a booking, change, cancellation or human-support request.
2. Check: read current availability; create a reception request if the connection fails.
3. Book: verify the calendar write succeeded and prevent duplicate or simultaneous bookings.
4. Confirm: state the date and time only after the responsible system confirms them.
5. Remind and reconcile: schedule the agreed messages and remove pending reminders when the appointment changes or is cancelled.

Test reminder frequency with the practice. Read-only availability access is not enough to guarantee booking. If the current calendar lacks the required API, alternatives include its official booking link, a request for reception or a custom scheduling system.

7 · Sent, delivered and completed are different events

An API acceptance response does not prove delivery. Record the message identifier and reconcile sent, delivered or failed statuses and their errors. Meta's official collection describes these statuses. Attendance is checked later in the calendar, not through a chat read receipt.

Our documented ghost-message integration story, in Spanish, illustrates why this matters. It does not establish that every out-of-window error behaves identically.

8 · Costs and measurement before expansion

Meta's official pricing page describes per-delivered-message charges by category and market, with specific exemptions and conditions. Do not budget using the old conversation unit or assume the Meta fee is the whole system's cost.

Separate implementation, monthly operation, messaging, model usage, infrastructure and scheduling integration. MD rates require an account; your proposal confirms inclusions. Before the pilot, record requests, confirmed bookings, changes, delivery failures and attendance. Compare similar periods and note closures, campaigns or staffing changes.

Continue with our no-show reduction strategies and the demo using a sample calendar. To assess your current system, book a free 30-minute discovery call. The diagnosis defines what to automate, what to keep manual and what the practice must approve.