Scheduling
Die Scheduling API ermöglicht patientenseitige Selbstbuchung für Videosprechstunden. Öffentliche Discovery-Endpunkte können mit einershop_uid aufgerufen werden. Buchungs- und Umbuchungsvorgänge nutzen entweder einen Organisations-API-Key oder einen kurzlebigen Patient Booking Token.
Authentifizierung
Die Scheduling API akzeptiert zwei Credentials. Die meisten Endpunkte akzeptieren beides; einige sind auf eines beschränkt.Patient Booking Tokens (empfohlen für Patientenflüsse)
Ein kurzlebiges JWT, das Ihr Partner-Backend für einen bestimmten Patienten ausstellt. Übergeben Sie es im HeaderX-RxScale-Booking-Token. Das Token wird gegen ein in RxScale hinterlegtes Organisations-Booking-Token-Secret verifiziert.
Algorithmus: HS256
JOSE-Header: muss kid enthalten — die key_id, die beim Provisionieren des Secrets zurückgegeben wurde.
Erforderliche Claims:
| Claim | Typ | Beschreibung |
|---|---|---|
aud | string | Muss rxscale-scheduling sein. |
exp | int | Ablauf (Unix-Sekunden). Kurz halten — unter 5 Minuten ist üblich. |
nbf | int | Not-before (Unix-Sekunden). |
iat | int | Issued-at (Unix-Sekunden). |
shop_identifier | string | Der in RxScale konfigurierte Shop-Identifier. |
shop_customer_id | string | Ihre stabile Kunden-ID. RxScale dedupliziert Patienten anhand dieser ID. |
patient_profile_fields | array | Profilfelder, die übernommen werden sollen. Jeder Eintrag: { "field": "<field_key>", "value": <wert>, "source": "shop" }. |
Booking-Token-Secrets werden in der RxScale-Datenbank verschlüsselt gespeichert. Nur Ihre
key_id liegt im Klartext für das Routing vor; der Secret-Wert wird sowohl bei der Token-Verifikation als auch beim Abruf durch einen Admin (Admin-Portal oder Secrets-API) im Speicher entschlüsselt. Rotieren Sie, indem Sie ein neues Secret provisionieren und das alte widerrufen, sobald Ihr Minter umgestellt ist.Organisations-API-Key
Senden SieX-API-Key: <key> statt des Booking Tokens für Server-zu-Server-Flüsse. Der Key benötigt die Berechtigung scheduling:write. Nutzen Sie das für Back-Office-Tools, skriptgesteuertes Umbuchen oder Operations-Skripte.
Terminarten auflisten
Shop-UID, mit der die Terminarten auf die richtige Organisation eingeschränkt werden.
Slots suchen
0 Minuten. Terminarten mit
selected_doctors_only liefern nur Ärzte mit aktiver arztspezifischer
Einstellung zurück.
Fensterstart (Unix-Sekunden).
Fensterende (Unix-Sekunden). Max. 31 Tage ab
from.Auf einen Arzt einschränken.
Booking Session erstellen
Verwenden Sie diesen Endpunkt beim Start der gehosteten UI oder des Widget-Skripts. Die Anfrage kann das signierte Patient Booking Token entweder inX-RxScale-Booking-Token oder im JSON-Body als booking_token enthalten.
booking für einen neuen Termin, rebooking für eine bestehende Buchung.Pflicht im
booking-Modus.Fensterstart (Unix-Sekunden). Pflicht im
booking-Modus.Fensterende (Unix-Sekunden). Pflicht im
booking-Modus.URL, zu der der Patient nach erfolgreicher Buchung weitergeleitet wird.
Patient Booking JWT, falls nicht im Header übergeben.
Booking Session abrufen
Die gehostete UI ruft diesen Endpunkt nur mit dem Launch-Code auf, um den Buchungskontext zu laden. Kein Auth-Header nötig — der Launch-Code selbst ist das Credential.patient_profile_uid und keine weiteren Patienten-Identifier, damit der Launch-Code gefahrlos durch die URL im Browser des Patienten geführt werden kann.
Holds erstellen und bestätigen
Authentifizierte Integrationen können Holds mit einem API-Key mitscheduling:write anlegen. Gehostete-UI-Integrationen nutzen die booking_launch_code-Routen.
Unix-Sekunden.
Optional. Derselbe Key mit identischem Body liefert den bestehenden Hold zurück, statt einen neuen anzulegen.
Wenn ein Hold abgelaufen ist, der Slot aber noch nicht durch einen anderen Termin belegt wurde, ist die Bestätigung weiterhin möglich und der Termin wechselt in den Status
confirmed.Termin stornieren
Storniert einen bestätigten oder gehaltenen Termin. Akzeptiert entweder ein Booking Token (patientenseitige Stornierung) oder einen Organisations-API-Key (Operations).Optionaler Freitext-Grund. Wird am Termin für Audit-Zwecke gespeichert.
cancellation_min_notice_minutes der Terminart. Eine Stornierung innerhalb der Frist gibt 400 mit dem betroffenen Feld zurück; buchen Sie den Patienten um oder rufen Sie den Endpunkt mit einem API-Key auf, wenn ein operativer Override nötig ist.
Termin umbuchen
Verschiebt einen bestehenden Termin auf einen neuen Slot. Der Rebook-Flow legt atomar einen neuen Termin an (mitprevious_meeting_uid auf den Originaltermin) und storniert den alten.
Unix-Sekunden für den neuen Slot.
Pflicht, wenn die Terminart
rebooking_mode: any_doctor setzt. Bei same_doctor_only wird der ursprüngliche Arzt übernommen.Optional. Standard ist die ursprüngliche Terminart.
Dringend empfohlen — schützt vor doppelten Umbuchungen bei Retries.
allow_patient_rebooking: false setzt, rebooking_min_notice_minutes nicht eingehalten ist oder der neue Slot bereits belegt ist.
Join-Token abrufen
Liefert ein kurzlebiges Jitsi-Waiting-Room-JWT und den Raumnamen. Wird von der Patient-UI verwendet, um den Videocall zu starten.Join-Fenster
Der Endpunkt akzeptiert Join-Anfragen ab 10 Minuten vorstart_date des Termins bis 60 Minuten nach end_date. Anfragen außerhalb dieses Fensters liefern:
Gehostete UI
Leiten Sie den Patienten auf dielaunch_url aus der Booking-Session-Antwort weiter oder binden Sie das Widget-Skript ein:
Arztportal-Endpunkte
Diese Endpunkte sind auf den authentifizierten Arzt (Auth0-Token) eingeschränkt und werden vom RxScale-Arztportal genutzt. Partner müssen sie in der Regel nicht direkt aufrufen.Geplante Termine auflisten
status, from, to, patient_uid, page, limit.
Die Antwort enthält ausschließlich Termine des authentifizierten Arztes.
Verfügbarkeits-CRUD
weekday (0 = Montag … 6 = Sonntag), start_time und end_time in Minuten seit
Mitternacht, optional buffer_minutes zwischen Slots sowie optionale Gültigkeitsgrenzen
valid_from / valid_until (Unix-Sekunden). PATCH-Bodies sind partiell; mit
clear_valid_from: true oder clear_valid_until: true lassen sich gesetzte Grenzen entfernen.
DELETE ist ein Soft-Delete.
Admin-Endpunkte
Auf die authentifizierte Admin-Organisation (Auth0-Token) eingeschränkt.Termine auflisten
doctor_uid, patient_uid, status, from, to, page, limit. Standard:
aktive (gehalten + bestätigt) Termine ab jetzt; mit status=all und from=0 lässt sich die
Historie einsehen.
Termin stornieren
{"reason": "..."} erforderlich.
Terminart-Erinnerungen
recipient_role (patient / doctor / admin), minutes_before (positive
ganze Zahl bis 60 Tage), send_email, send_sms und active. Mehrere Erinnerungen pro
(appointment_type, recipient_role) sind erlaubt, solange sich der minutes_before-Offset
unterscheidet.
Ein Maintenance-Job läuft jede Minute, findet bestätigte Termine, deren Auslösefenster “jetzt”
umfasst, und publiziert pro auflösbarem Empfänger ein scheduling.appointment_reminder_due-Event.
Das Event feuert immer (Partner-Webhook-Subscriber erhalten es); der RxScale-eigene
Notification-Handler verschickt E-Mail/SMS nur, wenn die jeweiligen Flags send_email /
send_sms auf der Erinnerungszeile gesetzt sind.
Partner abonnieren das Event über den bestehenden Endpunkt für Organisations-
Benachrichtigungs-Abonnements mit notification_type=APPOINTMENT_REMINDER_DUE.
Verfügbarkeiten eines Arztes ansehen
404 zurück, wenn der
Arzt nicht in der Organisation des Admins ist.
Booking-Token-Secrets
POST legt ein neues Secret an und gibt {key_id, secret} zurück. GET liefert den Wert
entschlüsselt zurück — Secrets liegen verschlüsselt in der Datenbank, sind aber von Admins
jederzeit über die API und das Admin-Portal (Einstellungen → Buchungs-Secrets) wieder lesbar,
damit ein neuer Minter ohne Neu-Provisionierung konfiguriert werden kann. DELETE widerruft
das Secret.
Die legacy organisations-gebundenen Pfade
(/v1/admin/scheduling/organisations/{organisation_uid}/booking-token-secrets[/<key_id>])
werden weiterhin akzeptiert und gegen die authentifizierte Organisation validiert.
Fehler
Die Scheduling API nutzt Standard-HTTP-Statuscodes:| Status | Bedeutung |
|---|---|
400 | Schema-Validierung fehlgeschlagen oder eine Geschäftsregel hat die Aktion blockiert (Details im error-Body). |
401 | Booking Token oder API-Key fehlt oder ist ungültig. |
404 | Ressource nicht gefunden oder der Aufrufer ist nicht berechtigt, sie zu sehen. Bei unberechtigtem Zugriff liefert die API 404, um Resource-Enumeration zu verhindern. |
409 | Slot wurde zwischen Hold und Confirm anderweitig belegt. Neu suchen und erneut versuchen. |
429 | Rate Limit (10 Anfragen pro Sekunde pro Service). Backoff und retry. |