Webhook-Ereignisse
RxScale sendet Webhooks für die folgenden Ereignistypen:HTTP-Header
Webhook-Anfragen enthalten die folgenden HTTP-Header:
Falls Sie beim Erstellen des Abonnements einen benutzerdefinierten Header konfiguriert haben, wird dieser ebenfalls mitgesendet. Test-Webhooks sind nicht signiert und enthalten stattdessen den Header
X-Webhook-Test: true.
pharmacy_order_created
Wird gesendet, wenn eine neue Apothekenbestellung erstellt und Ihrer Apotheke zugewiesen wird.Eine Apothekenbestellung wird pro Fulfillment erstellt, nicht pro Shop-Bestellung. Eine Shop-Bestellung kann daher im Lauf der Zeit mehrere Apothekenbestellungen erzeugen — zum Beispiel, wenn sie in mehrere Fulfillments aufgeteilt wird oder später ein Fulfillment hinzukommt. Diese Apothekenbestellungen haben dieselbe
data.order.uid. Verwenden Sie data.uid als Schlüssel einer Apothekenbestellung; shop_order_name ist nicht eindeutig. Details finden Sie unter Apothekenbestellungen.Apothekenbestellungen werden auch für rezeptfreie (OTC) Käufe erstellt, nicht nur für rezeptpflichtige Bestellungen — jede Ihrer Apotheke zugewiesene Erfüllung löst dieses Ereignis aus, unabhängig davon, ob ein Rezept vorliegt. Bei einer reinen OTC-Bestellung sind
data.doctor_data und data.prescription_file null, und data.prepaid ist 0.data.shipments ist immer vorhanden. Bei der Erstellung ist es ein leeres Array — die Apotheke hat noch nicht versendet. Nachdem die Apotheke Pakete hinzugefügt hat (Apothekenportal oder complete_order mit tracking_links), enthalten spätere pharmacy_order_updated-Zustellungen diese Sendungen.waiting for pharmacy. Die Payload zeigt die Bestellung so, wie sie beim Versand der Zustellung ist; eine pharmacy_order_created-Zustellung kann daher bereits einen späteren Status enthalten.
Mögliche status-Werte: waiting for pharmacy, pending review, on-hold, in-progress, ready_for_pickup, completed, cancelled
Payload-Beispiel
Feldreferenz
shipping_costs_amount und unpaid_shipping_costs_amount sind unterschiedliche Felder — die Garantie „0, niemals null” gilt nur für das erste.data.order.shipping_costs_amount ist immer ein Integer: 0, wenn keine Versandkosten anfallen, niemals null.unpaid_shipping_costs_amount ist eine separate, interne Überschreibung der Versandkosten, die nullable ist und nicht Teil des dokumentierten Webhook-Vertrags ist. Wenn Sie dieses Feld in einer Payload sehen, wenden Sie die Garantie von shipping_costs_amount nicht darauf an: Es kann fehlen oder null sein, und null bedeutet dort nicht „keine Versandkosten”. Verwenden Sie shipping_costs_amount für den Versandkostenabgleich und behandeln Sie unpaid_shipping_costs_amount — sofern Sie es überhaupt auslesen — als optionalen, möglicherweise null-Wert.pharmacy_order_updated
Wird gesendet, wenn sich eine bestehende Apothekenbestellung ändert:- Statusänderungen — im Apothekenportal (einschließlich Sammelaktualisierungen), über die External Pharmacy API (einschließlich Ihrer eigenen Aufrufe von
PATCH .../statusundcomplete_order) oder durch die automatische Statusabfrage bei Ihrem Apothekensystem (zum Beispiel, wenn es die Bestellung als versendet, abgeschlossen oder storniert meldet). - Stornierungen — unabhängig davon, ob die Bestellung von Ihrer Apotheke, vom Admin-Team oder durch die automatische Statusabfrage storniert wird.
- Sendungen — wenn im Apothekenportal eine Sendung manuell erfasst wird oder wenn Sie die Bestellung über die External Pharmacy API mit
tracking_linksabschließen. Eine als Carrier-Label gebuchte Sendung erscheint in der nächsten Aktualisierung (siehe Sendungen). - Klärfälle — wenn Ihre Apotheke oder das Admin-Team einen Klärfall zur Bestellung eröffnet, wodurch sie auf
on-holdgesetzt wird. - Priorität oder Versandart — wenn Ihre Apotheke die Priorität oder die Versandart der Bestellung im Apothekenportal ändert.
pharmacy_order_created und enthält immer den vollständigen aktuellen Stand der Bestellung, nicht nur den geänderten Teil. Das Feld status enthält den aktuellen Status, und data.shipments listet alle aktuell zur Bestellung gehörenden Sendungen auf (nicht nur die zuletzt hinzugefügte). Was sich geändert hat, ermitteln Sie durch Vergleich mit Ihrem gespeicherten Stand — siehe Ereignisse idempotent verarbeiten.
Es gibt kein separates Ereignis pharmacy_order_shipment_created. Abonnieren Sie pharmacy_order_updated und lesen Sie data.shipments.
Payload-Beispiel
Sendungen
data.shipments ist die Liste der Pakete, die die Apotheke zu dieser Bestellung erfasst hat. Nutzen Sie sie, um Tracking-Daten zu übernehmen, wenn eine Apotheke versendet — einschließlich Teillieferungen (mehrere Pakete).
Wann das Array befüllt ist
- Der Abschluss der Bestellung über
PATCH /v1/external_pharmacy_api/pharmacy_orders/{uid}/complete_ordermittracking_linkslegt eine Sendung an und sendet anschließendpharmacy_order_updated. - Das Hinzufügen einer Sendung im Apothekenportal (manuelles Tracking oder ein gebuchtes Carrier-Label, dem eine Bestellaktualisierung folgt) belässt die Sendung an der Bestellung. Die nächste
pharmacy_order_updated-Payload enthält alle aktuellen Sendungen, sortiert nachsequence_number. pharmacy_order_createdhat fast immer"shipments": []. Behandeln Sie eine fehlende Tracking-URL bei der Erstellung nicht als Fehler.
- Behandeln Sie
uidals stabile Identität eines Pakets. Ein späterespharmacy_order_updatedkann weitere Einträge hinzufügen; bestehende UIDs bleiben gleich. - Bevorzugen Sie
tracking_urlfür die kundenseitige Sendungsverfolgung.tracking_numberundcarrier_namesind gesetzt, wenn Apotheke oder Carrier sie geliefert haben; beide können bei einer neu angelegten Platzhalter-Sendungnullsein. is_testist nurtrue, wenn das Paket gegen eine Carrier-Sandbox gebucht wurde (kein echter Versand). Ignorieren Sie Testsendungen für die Live-Erfüllung.return_tracking_numberundreturn_label_expiry(YYYY-MM-DD) sind nur gesetzt, nachdem ein Rücksendeetikett ausgestellt wurde; sonst sind sienull.
Interne Speicherorte der Etikettendateien sind nicht Bestandteil des Webhooks. Verwenden Sie
tracking_url / tracking_number für die Sendungsverfolgung, nicht Speicherpfade.Webhooks auf Organisationsebene
Wenn das Webhook-Abonnement über die Management API (auf Organisationsebene) erstellt wurde, unterscheiden sich Bestellereignisse wie folgt:- Die
sku-Objekte inorder_itemsundfulfillment.itemswerden um Shopify-Bezeichner (shop_variation_id,shop_product_external_id) erweitert. - Ein
fulfillment-Objekt mit Details zur Fulfillment-Bestellung wird hinzugefügt. prescription_fileist nicht enthalten.
Das
fulfillment-Feld und die Shopify-Bezeichner (shop_variation_id, shop_product_external_id) in sku-Objekten sind nur in Webhook-Zustellungen auf Organisationsebene enthalten. Webhooks auf Apothekenebene enthalten diese Felder nicht.pharmacy_sku_stock_updated
Wird gesendet, wenn sich der Lagerbestand einer Apotheken-SKU ändert. Dies umfasst:- Direkte Bestandsaktualisierungen über die Pharmacy-API (
PATCH /v1/.../pharmacy_skus/{uid}/stockoder Inventar-Endpunkte). - Automatische Bestandsreduzierung bei Abschluss einer Apothekenbestellung. Dies wird sowohl beim manuellen Abschluss (über die Apotheken-Oberfläche / API) als auch beim automatischen Abschluss ausgelöst, wenn RxScale über die Statusabfrage-Integration mit dem Backend der Apotheke erkennt, dass die Bestellung versendet oder abgeschlossen wurde. Pro Apotheken-SKU der abgeschlossenen Bestellung wird ein Event emittiert.
Payload-Beispiel
Feldreferenz
Webhooks auf Organisationsebene
Wenn das Webhook-Abonnement über die Management API (auf Organisationsebene) erstellt wurde, enthalten Lagerbestandsereignisse zusätzliche Daten:- Das
sku-Objekt wird um Shopify-Bezeichner (shop_variation_id,shop_product_external_id) erweitert. - Ein
shop_identifier-Feld wird auf derdata-Ebene hinzugefügt.
Das
shop_identifier-Feld und die Shopify-Bezeichner (shop_variation_id, shop_product_external_id) im sku-Objekt sind nur in Webhook-Zustellungen auf Organisationsebene enthalten. Webhooks auf Apothekenebene enthalten diese Felder nicht.appointment_reminder_due
Wird gesendet, wenn eine konfigurierte Terminerinnerung fällig wird. Dieses Ereignis wird ausschließlich an Webhook-Abonnements auf Organisationsebene geliefert.Erinnerungen können für den Patienten auch direkte Aktions-Links enthalten (Beitreten, Umbuchen, Stornieren) — über RxScales eigene E-Mail-/SMS-Inhalte. Die Felder
rebook_allowed und cancel_allowed unten zeigen an, ob diese Aktionen aktuell verfügbar sind — sie sind ausschließlich true, wenn recipient_role gleich patient ist.Payload-Beispiel
Feldreferenz
patient_doctor_meeting_updated
Wird gesendet, wenn eine Patient-Arzt-Besprechung ihren Lebenszyklus-Status ändert. Dieses Ereignis wird ausschließlich an Webhook-Abonnements auf Organisationsebene geliefert (registriert über die Management API). Möglichechange-Werte:
Verwenden Sie
change als maßgeblichen Indikator für das eingetretene Ereignis. status spiegelt den aktuellen Datenbankstatus der Besprechung wider und ist bei On-Demand-Besprechungen null.Payload-Beispiel
Feldreferenz
Abonnieren
Abonnieren Sie über die Management API, um dieses Ereignis zu empfangen:E-Mail-Benachrichtigungen
Unabhängig von Webhooks kann eine Organisation RxScale den Patienten, den Arzt und/oder ihre Admins per E-Mail informieren lassen, wenn eine Besprechung bestätigt, storniert oder verschoben wird. Admins konfigurieren das im Tab “Benachrichtigungen” im Admin-Portal; standardmäßig ist es ausgeschaltet.confirmed ist unabhängig von den beiden anderen Änderungen abonnierbar —
das Aktivieren erfordert nicht, dass auch E-Mails zu Absage oder Verschiebung aktiviert sind.
Am Webhook-Verhalten ändert das nichts. Das Ereignis feuert weiterhin bei jedem oben
aufgeführten Übergang, mit unverändertem Payload — unabhängig davon, ob ein E-Mail-Abonnement
besteht. Der Webhook-Payload selbst bleibt durch dieses Feature unverändert.
Ein Unterschied ist bei der Planung zu beachten: Eine Verschiebung veröffentlicht zwei
Ereignisse — cancelled für die alte und rebooked für die neue Besprechung —, versendet aber
höchstens eine E-Mail, nämlich die zur Verschiebung. Wenn Sie diesen Stream in Ihre eigene
Patientenkommunikation spiegeln, wenden Sie dieselbe Regel an, sonst hört der Patient erst
“storniert” und dann “verschoben”. confirmed ist nicht Teil einer Verschiebung und hat keine
solche Paarung: Es wird einmalig für eine frische Buchung veröffentlicht und löst höchstens eine
Bestätigungs-E-Mail aus.
Zustellung und Idempotenz
Webhooks werden mindestens einmal zugestellt. Ihr Endpunkt sollte Zustellungen als idempotent behandeln und die Kombination ausdata.meeting_uid und data.change als eindeutigen Schlüssel verwenden — erneut zugestellte Events tragen dieselben Werte.