Pharmacy Orders
Manage pharmacy orders — view incoming prescription orders and update their status as you process them.List Orders
Page number (0-indexed)
Number of items per page (max 200)
Filter by status (e.g.,
waiting for pharmacy, on-hold, in-progress, completed)Search term. Case-insensitive substring match against shop order name (e.g.
#1234), pharmacy order name, patient name, order UID, and pharmacy order UID.Required for group-wide API keys
Response
Order Response Fields
Human-readable shop order name from the originating shop (e.g.
#1234). null for orders without a linked shop order.Shop shipping methods attached to the connected shop order. Each entry includes
the shop method (
uid, display_name, external_id) and the pharmacy-specific
mapping when one has been configured.Pharmacy-specific mapping for this shop shipping method. When present, it includes
pharmacy_uid and shipping_method_identifier_for_pharmacy.Shipping costs in cents, for example
499 for EUR 4.99. This value is separate
from product line item prices.ISO currency code for the shipping costs, for example
EUR.Priority hint for handling order sooner. Higher = more urgent.
0 means no special priority.Shop shipping methods come from connected shop orders. Pharmacists can configure
pharmacy-specific identifiers for each shop shipping method in the pharmacy tool
settings. If no mapping exists yet, the API still returns the shop shipping method
with
pharmacy_mapping: null. After a pharmacist saves a mapping, future order
responses include the configured shipping_method_identifier_for_pharmacy.Get Order Details
Response (additional fields)
Payouts
Order detail responses include top-levelpayouts. Each entry uses the same shape as the Payouts endpoint.
Payout components for this pharmacy order where the requested pharmacy is the receiver. Paid physical-prescription orders return
projected payout previews based on current order values and routing configuration. Completed orders return routed payouts once a persisted split-payment route exists.projected for an indicative preview, or routed for a persisted split-payment route created after pharmacy order completion.Payout amount in cents.
ISO 4217 currency code, for example
EUR.The payout component, such as
item_rest, item_markup, or shipping.Human-readable description of the routed or projected component.
Payment provider route identifier. This is populated for routed payouts when the provider returned an identifier, and
null for projected payouts.UID of the related pharmacy order.
Human-readable pharmacy order name, for example
#1001.Unix timestamp when the pharmacy order was created.
Unix timestamp when the split-payment route was created. This is
null for projected payouts and populated for routed payouts.Update Order Status
Request Body
New order status. See the table below for accepted values.
Free-text explanation for the status change. Required (and must be non-blank) when transitioning to
on-hold from any other status — the comment becomes the description of the admin issue thread that is automatically opened for the on-hold. Ignored for all other status transitions.Allowed Status Values
| Status | Description |
|---|---|
waiting for pharmacy | Order is in your queue, waiting to be processed |
pending review | Order is being reviewed |
on-hold | Order is paused while the pharmacy and admin team clarify an issue |
in-progress | Order is being prepared |
ready_for_pickup | Order is packed and ready for pickup or shipping |
cancelled | Order was cancelled |
Putting an Order On Hold
When you move an order intoon-hold, you must include a comment describing why the order is being paused. RxScale opens an admin issue thread automatically and uses your comment as the thread description so the admin team has the context they need to follow up.
comment, or with a comment that is only whitespace, returns a 400 response with body:
on-hold PATCH requests for an order that is already on-hold do not require a new comment — they are treated as idempotent re-sends.
Complete Order
orders_write permission.
Required for group-wide API keys
Request Body
tracking_links is optional. If provided, the first tracking link is forwarded with the shipment update.
Allowed carrier values are DHL, DPD, UPS, Hermes, FedEx, and Other.
Response
Validation Error Response
Whentracking_links contains an unsupported carrier or an invalid tracking link, the API returns 400 with the validation error and the pharmacy summary so you can map the error back to the affected pharmacy. If the order is already completed, calling complete_order again remains idempotent only when no tracking data is sent; tracking links on an already-completed order are rejected with 400 so shipment details are not silently dropped.