Skip to main content
When your integration is provisioned, your onboarding contact hands you a small, concrete kit. Everything below is what you need to make your first authenticated call and to watch your own progress — nothing more.

​
What you receive

  • Your API base URL — the test-environment base every example on this site calls $BASE_URL. All endpoints live under its /v1 path prefix, so a full request URL is always $BASE_URL/v1/.... It is issued together with your test API key; the production base is a later, separately-gated hand-off (see Environments).
  • Your member portal origin — the platform-hosted origin where your patients land once they log in: their plan, their orders, and the hosted identity step at /identity. Use it wherever your storefront links a patient to their account. See Login URLs and domains.
  • A brand id (brd_...) — the brand context every request carries in X-Brand-Id. One client can hold several brands; each call names exactly one.
  • Your offering references — the stable references you pass as offering when you send a patient in. They are opaque identifiers, never free-text product names, so renaming a product never breaks your links.
  • A redirect-allowlist confirmation — the exact return URLs your brand may send patients back to after login and after completion. Anything not on the list is dropped, fail-closed.
  • Your sign-in domain — your patients sign in on the shared platform domain, scoped to your brand through GET /v1/auth/login. A dedicated login domain of your own (and a custom member-portal domain) is a self-serve step with your API key — see Login URLs and domains; until yours is active, sign-in uses the shared domain.
  • A brand-config readback — a copy of the brand configuration as the platform has it: your theme, your offerings, and your allowlist, so you can confirm it matches what you expect before you go live.
  • A support contact — your onboarding contact is your point of contact for questions and requests while you integrate.
  • An onboarding id (onb_...) — your self-serve status handle. Read GET /v1/onboardings/{onboarding_id}/progress any time to see which step you are on and what is waiting on you. See the Onboarding timeline.

​
The two secrets you hold

Two of the values you hold are secrets. Each is shown to you exactly once and then held only by you — the platform never shows either again.
  • Your API key is issued by your onboarding team when your account is set up — there is no self-serve key generation. You receive it once, at issue; store it in your secret manager right away. Treat it as server-side only; never put it in browser code or a public repository. To replace one, ask your onboarding contact to rotate it.
  • Your webhook signing secret is the one you create yourself: it is generated when you call POST /v1/webhooks/registrations and returned exactly once in that response. The platform holds it after that and never returns it again. Store it the moment you receive it — it is what you verify delivery signatures with. If you lose it, register a new endpoint to mint a fresh one.
Keeping the secrets on your side is the point: no one, including us, can read your signing secret back out, so a delivery you accept is a delivery only you could have verified. For how each secret is issued, why it is shown once, and how rotation works, see Your credentials.

​
Before you make your first call

You are ready once you have your API key, your brand id, and at least one offering reference. From there, the Walkthrough takes you from sign-in to your first received event.