> ## Documentation Index
> Fetch the complete documentation index at: https://docs.purplelabelmd.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> What this API does and how its endpoints fit together.

This API lets you build a patient storefront: sign a patient in, run them through an intake
questionnaire, and follow their enrollment through to fulfillment. It is a REST API over HTTPS
with JSON request and response bodies, versioned under the `/v1` path prefix.

All examples on this site run against a **test-mode environment** with **test-scoped keys** and
**synthetic data only** — see [Environments](/pages/environments). The test-environment base URL
(`$BASE_URL` in every example) is issued together with your test API key, and every endpoint lives
under its `/v1` path prefix.

## How a request is authorized

Your server presents a per-client API key as a bearer token, and most endpoints also take a brand
header:

```
Authorization: Bearer <your-test-api-key>
X-Brand-Id: brd_<your-brand>
```

The key resolves to exactly one client (your tenant); the brand must belong to that client.

Two exceptions are worth knowing before you read further. The three sign-in endpoints under
`/v1/auth/` are browser redirects and take **no** key — you send the patient's browser through them.
And a second, **browser-safe** credential exists for the two brand reads a public storefront page
makes. Both are covered in [Authentication](/pages/authentication).

## The endpoints, grouped

The **API reference** tab groups every endpoint by area:

* **Sessions & authentication** — begin Universal Login, complete it, and log out
  (`/v1/auth/login`, `/v1/auth/callback`, `/v1/auth/logout`).
* **Intake** — start an intake session and walk it question by question
  (`/v1/instrument/resolve`, `/v1/instrument/next`, `/v1/instrument/abandon`). The server owns the
  question sequence, branching, and completion — a client can never skip or reorder questions.
* **Addresses** — as-you-type address suggestions for the intake flow
  (`/v1/instrument/address/suggest`).
* **Enrollment** — read the public status of a patient's enrollment
  (`/v1/journeys/{journey_id}/status`).
* **Onboarding** — read a client's onboarding progress
  (`/v1/onboardings/{onboarding_id}/progress`), plus the two brand reads a storefront makes before
  it renders a price (`/v1/account/brands/{brand_id}/storefront`,
  `/v1/account/brands/{brand_id}/readiness`).
* **Payments** — start a checkout session, read an order's payment status, and list your orders
  (`/v1/payments/checkout-sessions`, `/v1/payments/{order_ref}/status`, `/v1/account/orders`).
* **Brand configuration** — your brand's display identity, custom domains, and the browser origins
  your storefront may read from (`/v1/account/brands/{brand_id}/config`,
  `/v1/account/brands/{brand_id}/domains`, and the browser-origin allowlist).
* **Offering configuration** — enable offerings, set their price and display copy, and author the
  qualification questions attached to them (`/v1/account/brands/{brand_id}/offerings`,
  `/v1/account/brands/{brand_id}/pricing`, `/v1/account/question-library/...`).
* **Webhooks** — subscribe to platform events and manage delivery endpoints
  (`/v1/webhooks/event-types`, `/v1/webhooks/registrations`, and `/v1/webhooks/registrations/{registration_id}/test`).

## Conventions

* **IDs are opaque and prefixed** — for example `jny_` for an enrollment, `whr_` for a webhook
  registration. Treat them as strings.
* **Errors use [RFC 7807](https://www.rfc-editor.org/rfc/rfc7807)** `application/problem+json`
  bodies.
* **No patient data leaves through status reads** — enrollment and progress reads return
  identifiers and status values only.

Ready to make your first call? Start with the [Quickstart](/pages/quickstart).