Webhook-Ereignisse
RxScale sendet Webhooks für die folgenden Ereignistypen:HTTP-Header
Jede Webhook-Anfrage enthält die folgenden HTTP-Header:
Falls Sie beim Erstellen des Abonnements einen benutzerdefinierten Header konfiguriert haben, wird dieser ebenfalls mitgesendet.
pharmacy_order_created
Wird gesendet, wenn eine neue Apothekenbestellung erstellt und Ihrer Apotheke zugewiesen wird.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.status-Werte: init, waiting for pharmacy, pending review, in-progress, ready_for_pickup, completed
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. Dazu gehören:- Statusübergänge (z. B.
in-progress→completedoder eine Stornierung). - Das Hinzufügen einer oder mehrerer Sendungen durch die Apotheke — im Apothekenportal oder durch Abschluss der Bestellung über die External Pharmacy API mit
tracking_links.
pharmacy_order_created. 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).
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, enthalten Bestellereignisse zusätzliche Daten:- 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.
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.