Skip to main content

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.
Mögliche 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.
Das tatsächliche Zahlungsrouting erfolgt erst, wenn die Apothekenbestellung abgeschlossen wird. projected-Auszahlungen in Webhook-Payloads sind unverbindlich, werden nur für bezahlte Bestellungen mit physischem Rezept angezeigt und können sich vor Abschluss ändern. routed-Auszahlungswerte werden erst nach Abschluss und vorhandenem Routing befüllt.

pharmacy_order_updated

Wird gesendet, wenn sich eine bestehende Apothekenbestellung ändert. Dazu gehören:
  • Statusübergänge (z. B. in-progresscompleted oder 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.
Die Payload-Struktur ist identisch mit 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_order mit tracking_links legt eine Sendung an und sendet anschließend pharmacy_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 nach sequence_number.
  • pharmacy_order_created hat fast immer "shipments": []. Behandeln Sie eine fehlende Tracking-URL bei der Erstellung nicht als Fehler.
So verwenden Sie die Daten
  • Behandeln Sie uid als stabile Identität eines Pakets. Ein späteres pharmacy_order_updated kann weitere Einträge hinzufügen; bestehende UIDs bleiben gleich.
  • Bevorzugen Sie tracking_url für die kundenseitige Sendungsverfolgung. tracking_number und carrier_name sind gesetzt, wenn Apotheke oder Carrier sie geliefert haben; beide können bei einer neu angelegten Platzhalter-Sendung null sein.
  • is_test ist nur true, wenn das Paket gegen eine Carrier-Sandbox gebucht wurde (kein echter Versand). Ignorieren Sie Testsendungen für die Live-Erfüllung.
  • return_tracking_number und return_label_expiry (YYYY-MM-DD) sind nur gesetzt, nachdem ein Rücksendeetikett ausgestellt wurde; sonst sind sie null.
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 in order_items und fulfillment.items werden 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}/stock oder 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 der data-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ögliche change-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 aus data.meeting_uid und data.change als eindeutigen Schlüssel verwenden — erneut zugestellte Events tragen dieselben Werte.