Skip to main content

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:write on your API key.
  • A shop must exist first. Orders are created against a shop_identifier that 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

Required permission: 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:
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.
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.
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.
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.
A line cannot set both prescription_uid and prescription_reference — pick one. A prescription_reference that names no entry in this fulfillment’s own prescriptions array is rejected before anything is created.

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 per external_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:
Alternatively, the same information is available via a lookup:
This is the same List Orders endpoint already documented on the Orders page, filtered down to at most one result.

Add a Fulfillment

string
required
Your external_id for the existing order
Required permission: order: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 order
Required permission: order: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 order
string
required
Your external_id for the fulfillment to cancel
Required permission: order: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.
Cancellation is only possible while the fulfillment’s prescription (if it has one) has not yet reached a final state, and while no pharmacy is actively processing it. Once a doctor signs or declines the prescription, or a pharmacy starts working the order, cancelling is refused.

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 — use GET /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.