Order Status Updated

An order's status changed. All of these fire under the single eventType new_status_set_to_request, with the specific status in eventData.newStatus. targetEntity is the Order. The sub-pages here are examples for individual status values (started, requires_order_processing, requires_affiliate_review, provider review, waiting-room egress); the schema below is shared across all of them.

Field guarantees

Field	Guarantee
`eventData.newStatus`	✅ Always present (v1)
`eventData.performedBy`	⚠️ Conditional — set on only some firings (e.g. provider rejection)
`order_status` in v2	✅ Always present — carries the status value

📘
Unlike pharmacy_prescription_status_update, this event's newStatus does survive into v2: it aliases to order_status, which is on the ORDER allowlist. So on v2 the status value comes through as order_status.

v1 payload (legacy)

{
  "_id": "event::d6250393-xxxx-xxxx-xxxx-f8a8c24b93a8",
  "ownerEntityModel": "Patient",
  "targetEntityModel": "Order",
  "deleted": false,
  "ownerEntity": "pat::4f69cdbd-xxxx-xxxx-xxxx-e7964587a9b3",
  "targetEntity": "order::29876264-xxxx-xxxx-xxxx-d670b6fce60c",
  "eventTitle": "Upon order submission, it was determined to transition this order to started...",
  "eventType": "new_status_set_to_request",
  "eventData": {
    "newStatus": "started"
  },
  "createdAt": { "$date": "2023-04-27T15:22:50.523Z" },
  "updatedAt": { "$date": "2023-04-27T15:24:19.354Z" },
  "__v": 0
}

`eventData` field	Type	Always?	Notes
`newStatus`	string	✅	The order's new status (e.g. `started`, `requires_order_processing`)
`performedBy`	object	⚠️	Only on specific firings (e.g. a provider rejection)

v2 payload

Sanitized envelope. newStatus aliases to order_status (on the ORDER allowlist), so the status value is delivered. performedBy, when present, is stripped.

{
  "event_type": "new_status_set_to_request",
  "event_id": "event::d6250393-xxxx-xxxx-xxxx-f8a8c24b93a8",
  "api_version": "2026-08-09",
  "timestamp": "2026-05-30T14:00:00.000Z",
  "affiliate_id": "aff::xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "patient_id": "pat::4f69cdbd-xxxx-xxxx-xxxx-e7964587a9b3",
  "patient_external_id": "ext-patient-123",
  "patient_marketing_consent": false,
  "is_returning_patient": false,
  "order_id": "order::29876264-xxxx-xxxx-xxxx-d670b6fce60c",
  "order_status": "started"
}

Field	Delivered in v2	Notes
Envelope + patient identity	✅
`order_status`	✅	Carries the `newStatus` value
`order_id`, `subscription_status`, `product_variation_ids`	✅	Resolved from the order
`performedBy`	⛔	Stripped when present

Retrieving status reasons and history

To retrieve the human-readable reason for a status change (when present), or to see the full timeline of status changes, use the Order Status History field available in the GET /orders/{id} endpoint. This provides a curated, chronological list of all status changes for an order, including reasons for holds and rejections.

Field guarantees

Unlike pharmacy_prescription_status_update, this event's newStatus does survive into v2: it aliases to order_status, which is on the ORDER allowlist. So on v2 the status value comes through as order_status.

v1 payload (legacy)

v2 payload

Retrieving status reasons and history

Unlike `pharmacy_prescription_status_update`, this event's `newStatus` does survive into v2: it aliases to `order_status`, which is on the `ORDER` allowlist. So on v2 the status value comes through as `order_status`.