Order Intake
If your organisation does not sell through Shopify, order intake lets you push orders into RxScale directly from your own sales channel — your own website, POS system, or any other system of record. Everything downstream (prescriptions, pharmacy routing, fulfillment) works exactly the same way it does for a Shopify order; only how the order gets into RxScale differs.This is for your own integration, pushing orders into your own organisation. If you are a
telemedicine provider integrating into one of RxScale’s customer shops, see the
Public API instead.
Before You Start
- Required permission: every endpoint on this page requires
order:writeon your API key. - A shop must exist first. Orders are created against a
shop_identifierthat RxScale configures for your organisation when the integration is set up. Contact your RxScale account manager if you don’t have one yet. - Order status for your own customers lives elsewhere. This page only covers pushing orders in.
To check the status of an order as it moves through prescription review and pharmacy fulfillment,
use
GET /v1/management/orders— the read endpoints already documented on the Orders page.
Four Operations
Fulfillments are immutable. There is no endpoint to change the items on a fulfillment once it
is created. To change what is dispensed, cancel the fulfillment and create a new one with the
corrected items — this also starts a fresh prescription for the new items.
Create an Order
order:write
Creates an order together with its first fulfillment (or several fulfillments at once). Creation is
strictly once per external_id — see Retries and Duplicate Requests
below.
Request Body
Customer Object
Address Object
Money Object
RxScale never accepts decimal or floating-point amounts — amounts are always integers in the currency’s minor unit (cents for EUR), the same convention used throughout the platform.Fulfillment Object
A fulfillment is a group of items that ships and is prescribed together. Most orders have one; an order with items from different pharmacies or with different readiness (e.g. one item ready to ship, one still pending a prescription) has several.Item Object
Linking a Prescription
A line item needs a prescription whenever its product requires one. There are four ways to satisfy that, and every line uses exactly one of them:Over the counter -- no prescription needed
Over the counter -- no prescription needed
Leave
prescription_uid, prescription_reference, and anamnesis_uid all unset. Only valid for
products in your catalogue that are configured as not requiring a prescription.Send to an RxScale doctor
Send to an RxScale doctor
Set
anamnesis_uid to the uid of a completed questionnaire response for this customer. An
RxScale doctor reviews it and issues the prescription; the order moves to
waiting for doctor until they do.Reference a prescription you already have
Reference a prescription you already have
Set
prescription_uid to the uid of a prescription that is already signed — for example,
one your integration obtained earlier through another RxScale flow. The prescription must
already belong to your organisation.Upload a signed PDF inline
Upload a signed PDF inline
Add an entry to the fulfillment’s own
prescriptions array: {"id": "your-reference", "pdf_base64": "..."}. The PDF is validated for a qualified electronic signature (QES) as part
of the request — an unsigned or invalid PDF rejects the whole order, nothing is created. On the
line item, set prescription_reference to the same id you used in prescriptions. RxScale
turns the upload into a prescription and links it to the line automatically; from that point on
it behaves exactly like the previous option.Example Request
Response (201 Created)
Error Responses
When a request is rejected, nothing is created — not the order, not a prescription from an
inline PDF, nothing.
external_id stays free to retry with a corrected payload.Retries and Duplicate Requests
Order creation is strictly once perexternal_id: POSTing the same external_id a second time
always returns 409 with code: "order_already_exists", even if the first request’s response
never reached you (a timeout, a dropped connection). The 409 body carries the existing order’s
order_uid, so recovering from a lost response needs no follow-up call — just retry with the same
payload and read order_uid off the error:
Add a Fulfillment
string
required
Your
external_id for the existing orderorder:write
Adds a new fulfillment (and its items) to an order that already exists. The request body is a
single Fulfillment object — not wrapped in an order. Use this when items in
the same order become available at different times, or need to be split across pharmacies.
A fulfillment external_id that already exists on this order is rejected: fulfillments cannot be
changed once created, only cancelled and replaced.
Example Request
Response (201 Created)
Error Responses
Update an Order
string
required
Your
external_id for the existing orderorder:write
Updates order-level fields that are not tied to items. Items are never accepted here — they
always arrive inside a fulfillment (see Add a Fulfillment); a request body
containing an items key is rejected.
Request Body
All fields are optional; send only what you want to change.Example Request
Response (200 OK)
Error Responses
Cancel a Fulfillment
string
required
Your
external_id for the orderstring
required
Your
external_id for the fulfillment to cancelorder:write
Cancels a fulfillment. This is the only way to change what a fulfillment contains — cancel it, then
add a new fulfillment with the corrected items.
Example Request
Response (200 OK)
Error Responses
Where Order Status Lives
This page covers pushing orders into RxScale. To track an order after that — its status, which prescription is attached, which pharmacy order was created — useGET /v1/management/orders and
GET /v1/management/orders/{order_uid},
already documented on the Orders page. If you are instead a telemedicine provider tracking orders
you placed through the Public API, order status for that flow lives in the
Public API — not here.