Skip to main content

Webhook Events

RxScale sends webhooks for the following event types:

HTTP Headers

Every webhook request includes the following HTTP headers: If you configured a custom header when creating the subscription, it will also be included.

pharmacy_order_created

Sent when a new pharmacy order is created and assigned to your pharmacy.
Pharmacy orders are created for over-the-counter (OTC) purchases too, not only for prescription-based orders — any fulfillment routed to your pharmacy triggers this event, whether or not it includes a prescription. For an OTC-only order, data.doctor_data and data.prescription_file are null, and data.prepaid is 0.
Possible status values: init, waiting for pharmacy, pending review, in-progress, ready_for_pickup, completed

Payload Example

Field Reference

Actual payment routing happens only when the pharmacy order is completed. projected payouts in webhook payloads are indicative, only shown for paid physical-prescription orders, and can change before completion. routed payout values are only populated after completion and routing exists.

pharmacy_order_updated

Sent when an existing pharmacy order’s status changes. The payload structure is identical to pharmacy_order_created. The status field reflects the new status.

Payload Example

Organisation-Level Webhooks

When the webhook subscription was created via the Management API (organisation-level), order events include additional data:
  • The sku objects inside order_items and fulfillment.items are enriched with Shopify identifiers (shop_variation_id, shop_product_external_id).
  • A fulfillment object is added with fulfillment order details.
The fulfillment field and the Shopify identifiers (shop_variation_id, shop_product_external_id) inside sku objects are only present in organisation-level webhook deliveries. Pharmacy-level webhooks do not include these fields.

pharmacy_sku_stock_updated

Sent when a pharmacy SKU’s stock level changes. This includes:
  • Direct stock updates via the Pharmacy API (PATCH /v1/.../pharmacy_skus/{uid}/stock or inventory endpoints).
  • Automatic stock reduction when a pharmacy order is completed. This fires for both manual completion (via the pharmacy UI / API) and automatic completion when RxScale detects the order has reached a shipped or completed state via its status-check integration with the pharmacy’s backend. One event is emitted per pharmacy SKU on the completed order.

Payload Example

Field Reference

Organisation-Level Webhooks

When the webhook subscription was created via the Management API (organisation-level), stock events include additional data:
  • The sku object is enriched with Shopify identifiers (shop_variation_id, shop_product_external_id).
  • A shop_identifier field is added at the data level.
The shop_identifier field and the Shopify identifiers (shop_variation_id, shop_product_external_id) inside the sku object are only present in organisation-level webhook deliveries. Pharmacy-level webhooks do not include these fields.

appointment_reminder_due

Sent when a configured appointment reminder becomes due. This event is delivered to organisation-level webhook subscriptions only.
Reminders can also carry direct action links for the patient (join, reschedule, cancel) via RxScale’s own email/SMS content. The rebook_allowed and cancel_allowed fields below tell you whether those actions are currently available — they are only ever true when recipient_role is patient.

Payload Example

Field Reference


patient_doctor_meeting_updated

Sent when a patient-doctor meeting changes lifecycle state. This event is delivered to organisation-level webhook subscriptions only (registered via the Management API). Possible change values:
Use change as the authoritative indicator of what happened. status reflects the meeting’s current database status and is null for on-demand meetings.

Payload Example

Field Reference

Subscribing

Subscribe via the Management API to receive this event:

Delivery and Idempotency

Webhooks are delivered at least once. Your endpoint should treat deliveries as idempotent using the combination of data.meeting_uid and data.change as the unique key — retried deliveries will carry the same values.