Developer Changelog

RxRelay API changes

Developer-facing changes to the RxRelay API, webhook events, documentation, and integration tooling.

2026-07-09

Per-pharmacy medication catalogs

  • GET/v1/pharmacies lists the distinct pharmacies your clinic can dispense from, each with a stable, opaque id and display name.
  • GET/v1/medications now accepts an optional pharmacyId query parameter — pass an id from GET/v1/pharmacies to retrieve just that pharmacy's formulary. Omit it for the clinic's full unified catalog, exactly as before.
  • A malformed pharmacyId returns 400; a well-formed id your clinic isn't entitled to returns an empty array. No existing response fields changed.
  • The hosted OpenAPI endpoint reflects these changes when the updated API is deployed.

2026-07-08

Register prescribers and users via the API

  • POST/v1/users creates or updates a user in your clinic and assigns clinic roles — register prescribers programmatically instead of the onboarding spreadsheet. The clinic comes from your API key, so no clinic reference is needed.
  • A prescriber must include an npi; once registered it can be referenced on orders by prescriberNpi. The call is idempotent per email — an existing email links to that user and merges roles.
  • GET/v1/users lists your clinic's users with roles and NPI, so you can check whether a prescriber is already registered before ordering.
  • GET/v1/clinic returns your clinic's own record — including its RxRelay clinic id and sandbox flag — for clinic-scoped keys.
  • Organizations gain GET/v1/clinics/{clinicRef}/users to list a clinic's users. On the org user endpoints, {clinicRef} is now the RxRelay clinic id (a UUID); the externalClinicId alias is no longer accepted there.
  • platform_admin can no longer be assigned through the API; assignable roles are prescriber, clinic_admin, staff, and owner.
  • The hosted OpenAPI endpoint reflects these changes when the updated API is deployed.

2026-07-08

Structured medication ingredients

  • GET/v1/medications now returns an ingredients array for each medication — the structured per-active composition (name, concentration, unit) when the fulfilling pharmacy provides it.
  • The array is empty when no structured data is available; strength stays the flat summary. For a multi-active blend, ingredients describes what a single strength value cannot.
  • ingredients is informational for display and selection — ordering is unchanged and still references a medication by id.
  • The hosted OpenAPI endpoint reflects these changes when the updated API is deployed.

2026-06-29

Generic order metadata

  • POST/v1/orders now accepts optional metadata: a generic key/value object for display and audit context.
  • Metadata is stored with the order, returned by order read/list APIs, shown on the RxRelay order detail page, and included in order webhooks.
  • Metadata is not used for auth, routing, billing, or fulfillment logic. Values must be string, number, boolean, or null; nested objects and arrays are rejected.
  • Limits are 20 keys, 64 characters per key, and 512 characters per value.
  • The hosted OpenAPI endpoint reflects these changes when the updated API is deployed.

2026-06-27

Expanded medication response

  • GET/v1/medications now returns strength, form, pharmacyName, and pharmacySku for each medication, in addition to id and name.
  • pharmacySku is the fulfilling pharmacy's own product identifier (the downstream SKU) for that medication — useful for reconciling RxRelay's catalog against a pharmacy's price list.
  • All four fields are populated when the fulfilling pharmacy provides them and are null otherwise.
  • The hosted OpenAPI endpoint reflects these changes when the updated API is deployed.

2026-06-27

Patient and order management endpoints

  • Added GET/v1/patients to list and search patients by name, email, phone, date of birth, or externalPatientId, with limit/offset pagination and a total count.
  • Added GET/v1/patients/{patientId} to fetch a single patient and its active addresses.
  • Added POST/v1/patients to create or resolve a patient outside of an order (by externalPatientId or email), with an optional default address.
  • Added PATCH/v1/patients/{patientId} to update patient demographics. Remapping externalPatientId to a patient already mapped elsewhere returns 409 Conflict.
  • Added GET/v1/orders to list and search orders by status, patient, externalOrderId, and date range, plus GET/v1/patients/{patientId}/orders for a single patient's orders. Both are paginated, newest first.
  • Added GET/v1/patients/{patientId}/addresses/{addressId}, DELETE on the same path to deactivate an address (promoting a new default if needed), and POST.../default to set an existing address as the default.
  • Reads work with any valid key; writes (POST/PATCH/DELETE) require a read_write key. Organization keys scope these via clinicId or externalClinicId.
  • The hosted OpenAPI endpoint reflects these changes when the updated API is deployed.

2026-06-23

Patient address IDs for partner orders

  • POST/v1/orders now accepts exactly one of shippingAddressId or shippingAddress. Existing shippingAddress behavior is preserved.
  • When a full shippingAddress exactly matches an existing patient address, RxRelay reuses that address instead of creating a duplicate.
  • Added GET/v1/patients/{patientId}/addresses and POST/v1/patients/{patientId}/addresses so partners can retrieve, upsert, store, and reuse RxRelay address IDs.
  • Patient address cards in the RxRelay app now show a copyable Address ID.
  • The hosted OpenAPI endpoint reflects these changes when the updated API is deployed.

2026-06-23

Webhook delivery decoupled from order submission

  • Outbound partner webhooks are now delivered asynchronously through the RxRelay worker instead of being attempted on the POST/v1/orders request path.
  • POST/v1/orders response bodies and webhook payloads are unchanged; partners should continue treating webhooks as asynchronous status events.
  • Webhook delivery remains single-attempt by default. Failed deliveries are recorded in the webhook event log and can be manually replayed from Settings / API.
  • The hosted OpenAPI endpoint continues to document POST/v1/orders as returning 201 Created.

2026-06-19

Organizations: order on behalf of clinics and provision via API

  • Added organization-scoped API keys. An organization owns many clinics and is issued one key instead of one key per clinic.
  • POST/v1/orders now accepts clinicId or externalClinicId. Organization keys must name the target clinic on each order; clinic-scoped keys are unchanged.
  • GET/v1/medications and GET/v1/prescribers accept a clinicId or externalClinicId query parameter to scope results for organization keys.
  • Added GET/v1/clinics to list the clinics under an organization.
  • Added POST/v1/clinics and POST/v1/clinics/{clinicRef}/users to provision clinics and their users — available to organization keys once RxRelay enables provisioning. Clinic creation is idempotent on externalClinicId.

2026-06-12

Required shipping address on orders

  • POST/v1/orders now requires a shippingAddress object (address1, address2, city, state, zip). Orders without a valid shipping address are rejected with 400.
  • The supplied address is saved as the patient's default address and sent to the fulfilling pharmacy.

2026-06-06

Developer platform foundation

  • Added clinic-scoped RxRelay API documentation under RxRelay Developers.
  • Added public OpenAPI endpoint at https://api.rxrelay.ai/openapi/v1.json.
  • Added request IDs, documented rate limits, idempotency behavior, and Problem Details errors.
  • Added webhook delivery event log with manual replay for failed deliveries.
  • Added order.tracking_updated webhook event for upstream tracking updates.