​

Managing appointments

Admins can review scheduled patient appointments and manage the scheduling configuration from the admin portal. The appointment overview is designed for support and operations teams that need to check upcoming bookings or cancel a booking on behalf of a patient or provider.

​

Where to find appointments

Use the global appointment overview to see bookings across your organisation. You can also open a patient profile and review that patient’s appointments from the patient detail page. By default, the overview shows future active appointments.

​

Filters

You can filter appointments by:

• Doctor
• Appointment type
• Patient
• Status
• Date range

​

Appointment statuses

• held means the slot is temporarily reserved but not confirmed yet.
• confirmed means the appointment is booked.
• cancelled means the appointment was cancelled.
• expired means a temporary hold expired before confirmation.
• completed means the appointment has finished.
• no_show means the patient did not attend.

​

Cancelling appointments

Admins can cancel active held and confirmed appointments. A cancellation reason is required. The reason is stored with the appointment so support and operations teams can understand why the booking was cancelled.

​

Booking token secrets

If your organisation mints patient booking tokens from a partner backend (for example a Shopify storefront), each token is signed against a secret that RxScale issues to you. Manage these from your organisation settings:

• Create a secret. RxScale returns a key_id (used in the JWT kid header) and the secret value. The value is stored encrypted at rest. Admins can reveal it again any time from the Settings → Booking secrets page, so re-pasting it into a new minter doesn’t require re-provisioning.
• Revoke a secret. Revocation is immediate. Any tokens signed by the revoked key are rejected on the next call.

​

Rotating a secret

1. Create a new secret. You now have two active secrets.
2. Update your minter to sign new tokens with the new key_id.
3. Wait for tokens signed with the old key to expire (typically a few minutes given the short token TTL).
4. Revoke the old secret.

Because each token is routed by its kid header, you can rotate without downtime.

​

Public booking links

A public booking link is a stable, shareable URL — unlike a booking token secret (above), which a partner backend uses to mint a one-time link for a specific patient, a public link is meant to be published somewhere a patient will find it: your website, a doctor’s bio, or an email signature. Anyone with the URL can book. Manage these from Settings → Public booking links.

​

Creating a link

Each link is scoped to:

• A shop — required. Determines which of your shops the link books into.
• An appointment type — required. Every link books exactly one kind of appointment.
• A doctor — optional. Pin the link to one doctor, for example on their personal bio page, or leave it open so it books with any available doctor in the shop.

You also choose a name for the URL (lowercase letters, digits and hyphens); RxScale appends a short random suffix so the full URL can’t be guessed. Optional settings include a return URL to send the patient to after they book, booking instructions shown before they pick a time, and whether a reason for the visit is required.

​

What visitors are asked for

A first-time visitor books with a verified email address, and is then asked for the patient profile fields you have marked Required for prescription for that link’s shop (manage these under Settings → Profile Fields). Nothing is hard-coded: mark an insurance number required and the booking form asks for it; leave date of birth unmarked and it is not asked for. Two things are deliberately left out:

• Photo and ID-document fields are never asked for here — the booking form is a text form with no upload — so marking one required does not stop patients booking. Collect these later in the consultation as usual.
• Fields the patient already has on file are skipped. A returning patient is only asked for what is still blank, and a value already on the record is never overwritten by the booking form.

If a shop has no required-for-prescription fields the form can collect, the visitor books on their verified email address alone. Each field is labelled with the name you gave it on the profile field itself, so what you type there is what the patient reads — worth a glance if any of your field names are internal shorthand. A few common fields (first name, last name, date of birth) keep RxScale’s own translated labels instead, so they read correctly in the patient’s language. Date fields get a date picker and phone fields a telephone keypad, based on the field’s type rather than its name.

​

The URL stays stable

Once created, a link’s URL doesn’t change by itself. Publish it anywhere and it keeps working until you deactivate, rotate, or delete it.

​

Deactivating, rotating, and deleting

• Deactivating a link (switching its Active setting off, from the edit dialog) stops it accepting new bookings immediately, but keeps the URL and its configuration in place. Nothing happens to appointments already booked through it. Switch it back on at any time to resume taking bookings at the same URL.
• Rotating keeps the link’s name but issues a new random suffix. The previous URL stops working immediately, everywhere it was published — your website, bios, and email signatures all need updating to the new one. Use this if a link’s URL ended up somewhere you didn’t intend, or you just want a fresh one.
• Deleting a link removes it permanently. Like deactivating, it doesn’t affect appointments already booked through it — only future bookings are.

​

Provisioning appointment types and meeting rooms

Appointment types are configured by the RxScale team during onboarding and on request. They define duration, hold TTL, cancellation notice, and rebooking rules. Reach out to support if you need a new appointment type, or a change to an existing one. Meeting rooms you manage yourself. Every doctor gets a persistent video room automatically when the doctor is created (persistent_per_provider strategy), so the patient and the doctor always land in the same Jitsi room. Open a doctor’s detail page to see the room and to create, rotate, or remove it. The room name is generated for you and is never something you supply.

• Creating a room applies to a doctor who has none — for example a doctor added before rooms were provisioned automatically.
• Rotating issues a new room name. Appointments already booked keep the name they were booked with, because each appointment stores its room name at the moment the slot is held; only bookings made after the rotation use the new name.
• Removing a room stops all new bookings for that doctor. Not even a hold can be created, so the doctor cannot be booked at all until a room exists again. Appointments already booked are unaffected and keep working. Create a room again to make the doctor bookable.

Treat a room name as confidential — it is the way into a live consultation.

​

Doctor availability windows

Doctors manage their own bookable windows. Each doctor sees an Availability page in their portal where they can add, edit, or remove weekly recurring slots that drive the patient booking page. As an admin you can review a doctor’s current windows from the doctor detail page — useful when troubleshooting why patients don’t see slots, or when auditing coverage — and you can add, edit or remove both weekly windows and single-date overrides there yourself. Changes you make take effect for patient bookings immediately, so coordinate with the doctor before altering their schedule.

​

Rebooking on behalf of a patient

You can move an existing appointment to a new slot from the appointment detail page. Rebooking honours the appointment type’s rebooking_mode (same doctor vs. any doctor) and minimum notice window. Admin rebooks are recorded as a new appointment linked to the original via previous_meeting_uid, so the audit trail is preserved.

​

Appointment reminders

You configure reminders per appointment type. Each reminder rule has:

• a recipient group — patient, doctor, or admin,
• a minutes_before offset (e.g. 60 = one hour before the appointment),
• send_email and send_sms toggles — when both are off, the event still publishes (partners can subscribe) but RxScale won’t dispatch anything itself.

You can stack multiple reminders per group, for example a doctor reminder 24h before plus a second 15 minutes before. The maintenance manager runs every minute and publishes one APPOINTMENT_REMINDER_DUE event per resolved recipient. Idempotency is guaranteed by an internal appointment_reminders_sent row so the same reminder never fires twice for the same appointment. To receive these events on your own systems, subscribe APPOINTMENT_REMINDER_DUE from the notification subscriptions page — the existing webhook subscription mechanism handles signing, custom headers, and retries the same way it does for prescription events.

​

Doctor phone numbers for SMS reminders

If your reminder rules turn on send_sms for the doctor recipient, RxScale needs a mobile number on the doctor’s profile to deliver the SMS. Doctors can set their own number from the Settings page in the Doctor Portal; admins can also edit it on the doctor detail page (the “Mobile phone number” field, separate from the prescription phone field).

​

Cancellation, rescheduling, and confirmation emails

RxScale can email your patients, your doctors, and your admins when a scheduled appointment is cancelled, rescheduled, or confirmed. This is separate from appointment reminders, and it is off by default: nothing is emailed until you create a subscription for it.

​

Turning it on

1. Open Settings → Notifications. This tab manages both webhook subscriptions and email notifications.
2. Create a subscription and set Channel to Email. The event type is Patient-doctor meeting updated.
3. Choose the Recipient — Patient, Doctor, or Admins. Each is its own subscription, so you can email any combination of the three.
4. Tick which changes send an email: Cancellation, Rescheduling, Confirmation, or any combination. At least one is required.

A reschedule counts only as a rescheduling. If you tick Cancellation alone, moving an appointment emails nobody — the cancellation half of a reschedule is deliberately suppressed, so there is nothing left for that subscription to match. Confirmation is independent of that suppression — it is not part of a reschedule at all, so ticking Confirmation always emails on a fresh booking, whether or not Cancellation or Rescheduling are also ticked. Editing a subscription later lets you change which changes send mail. Recipient and event type are fixed once created — to switch recipient, add a subscription for the other one. Delete the subscription to stop the emails entirely.

​

What the email says

The email is bilingual (German first, then English) and names the appointment type, the other party or parties, and the appointment time:

• Cancellation — states that the appointment was cancelled, and includes the cancellation reason when one was given.
• Rescheduling — states that the appointment was moved and gives the new time. It never repeats the old time, and if no new time is available it says only that it was moved.
• Confirmation — states that the appointment was confirmed, and gives the appointment time. It fires once, when a fresh booking is confirmed — a later reschedule of that appointment sends its own rescheduling email, not a second confirmation.

Patients and doctors are emailed at the contact address RxScale already holds for them; there is no new field to fill in. A patient or doctor with no contact address on file is not emailed. The wording is fixed and cannot be customised per organisation today, and only these three changes send email — the other transitions (held, expired, completed, no-show) never do, though they still fire webhooks. Delivery is best effort per recipient: if several recipients are subscribed and one send fails, the others are unaffected.

​

Admins fan out to every organisation user

Subscribing Admins does not pick a single person — it emails every user in your organisation who has an email address on file, the same way appointment reminder notices to admins already work. There is no per-user opt-out for this recipient; to stop the emails, delete or edit the subscription.

​

Doctors can switch off their own copy

If you subscribe Doctor, each doctor can still silence their own copy from the Settings page in the Doctor Portal, under Appointment update emails. Doctors receive these emails — including confirmations — unless they turn them off. Turning it off only stops that doctor’s own email — emails to patients and admins are unaffected.

​

Your webhooks do not change

Email is a separate delivery channel on the same subscription mechanism. The patient_doctor_meeting_updated webhook keeps firing on every meeting transition, with an identical payload, whether or not you have any email subscription. Existing integrations need no changes.

​

Connecting your Mollie account

Paid booking links need your own Mollie account. Connect it once under Settings -> Payments with Connect with Mollie; RxScale then creates payments on your account, the money lands in your balance, and RxScale takes its platform fee from each payment. You do not have to wait for Mollie to finish verifying you. You can connect a Mollie account that has just been created — during your onboarding call, for example. The connection is stored and the page shows it as awaiting verification. While it is in that state you cannot sell paid appointments yet: the billing step of the booking-link dialog stays closed, and no payment can be created. RxScale re-checks the account in the background, and again whenever you open the payments page. As soon as Mollie has verified your account and enabled payments on it, the connection switches to ready on its own — nobody has to open anything, and there is no need to run the connect flow a second time. The switch is silent: you will not get an email about it, so check the payments page if you want to know where your account stands. If your verification has just come through and you do not want to wait out that hour, use Check Mollie status now on the payments page. It asks Mollie immediately and tells you what came back — that payments are now enabled, that Mollie has still not enabled them, or that the access you granted RxScale no longer works and the account has to be reconnected.

​

Rehearsing paid bookings before you go live

Before you hand a priced booking link to a real patient, you can run the whole thing yourself — booking, checkout, confirmation, reminders, cancellation, refund — without any money moving. Put the appointment type into test mode.

​

Switching a type into test mode

Go to Settings → Appointment types, open Pricing for the type, choose Edit pricing, and set Payment mode to Test payments (no money is collected). Save. Test mode is set on one appointment type at a time. Every other appointment type keeps its own setting, so your live types carry on taking real payments while you rehearse with a dedicated test type.

​

It works while Mollie verification is still pending

Normally a priced booking link needs a Mollie account that Mollie has finished checking and enabled for payments. A test-mode appointment type does not wait for that verdict — you can rehearse the paid flow from day one, while your Mollie onboarding is still in progress.

​

What you and the patient will see

Test mode is deliberately loud. It appears at every point where somebody could mistake a rehearsal for a real booking:

• A Test mode badge beside the appointment type, in the types list and on the type’s own page.
• A notice in the booking-link dialog whenever you generate a priced link for that type — the moment a link could be handed to a patient who is meant to pay. An unpriced link takes no payment at all, so it carries no notice.
• A banner on the patient’s payment step: Test booking — you will not be charged.
• A Test payment badge on the appointment’s row in the appointments list, beside its status. It follows the payment rather than the appointment type, and it is shown whatever state that payment ended up in — including refunded, failed, cancelled and expired.
• A Test mode badge in the refund dialog, so an old test payment is never refunded in the belief that real money is going back.
• Different wording in the cancel dialog. Cancelling a paid appointment normally warns you that the whole remaining amount goes back to the patient; on a test payment that would be false, so the warning says instead that nothing was taken and nothing comes back.

​

No money moves

On a test payment:

• The patient is never charged, and nothing leaves their account.
• Nothing is paid out to your organisation, and there is nothing to reconcile.
• A refund repeats the flow with the payment provider but sends nothing back, because nothing was ever taken.

​

A test payment stays a test payment

Every payment records the mode it was taken in, and that never changes afterwards. Switching the appointment type back to live payments does not convert the test payments you already made: each one stays a test payment in the appointment list, and refunding it refunds it in test mode — the row keeps its Test payment badge and the refund dialog its Test mode badge, whatever the appointment type is set to by then. Only bookings made after the switch take real money.

​

Going live

Test mode does not expire and does not block anything, so nothing turns it off for you. When you are satisfied with the rehearsal, go back to Settings → Appointment types → Pricing → Edit pricing and set Payment mode back to Live payments — the normal setting for a paid appointment type. If you build your own booking front end instead of using the hosted one, the booking session tells you which mode a booking is about to be taken in: see billing.test_mode in the Scheduling API reference. Once a payment exists, read testmode on the payment itself instead. That one is fixed when the payment is created, while billing.test_mode follows the appointment type’s current setting — so it can change underneath a patient who is still at the checkout page.

​

Refunding a paid appointment

When an appointment was booked through a priced booking link, its row in the appointments list carries a payment, and a Refund action appears beside Cancel. The action is only shown when there is money that can still go back — an appointment nobody paid for, or one whose payment failed or has already been refunded in full, has no refund action at all. The refund dialog shows what the patient paid, what has already gone back, and what is still refundable, together with every refund made against that payment so far. You can:

• Refund in full — the default. It sends back everything still refundable, computed at the moment you confirm rather than at the moment the dialog opened.
• Refund part of it — enter an amount in euros, up to what is still refundable. You can do this more than once; each partial refund is recorded separately.

Optionally add a reason. On some payment methods it is shown to the patient, so write it as something the patient would understand.

​

Cancelling refunds automatically

Cancelling a paid appointment refunds the whole remaining amount. That happens however the cancellation is made — from this interface, from the Management API, from the patient’s own cancel link, or from the cancel link in a reminder email. The cancel dialog warns you when the appointment has a payment that will be sent back. Rebooking does not refund. Moving an appointment to a new time keeps the same payment against the same booking, so the patient is neither charged again nor refunded.

​

Refunds RxScale requests for you

If a payment arrives after its slot has been taken by somebody else — rare, but possible while a slow payment method settles — the appointment cannot be confirmed and the payment is flagged refund_required. RxScale requests the refund automatically; you do not need to do anything, and the refund appears in the dialog like any other.

​

When a refund cannot be made

A refund has to leave from the Mollie account that took the money. Two situations stop that:

• You disconnected and reconnected the same Mollie account. Refunds keep working — RxScale uses your current credentials for the same account.
• You connected a different Mollie account. The money is in an account RxScale can no longer reach, and refunding from the new one would take it out of the wrong balance. The refund is marked failed with that reason. Reconnect the original account and request the refund again.

A refund is also marked failed when the payment provider refuses it outright, or when the amount no longer fits because another refund settled in between. In every case the refund row records why, and you can request a new one once the cause is fixed.