Skip to main content
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. 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:
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.

​
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 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.