Skip to main content
Everything a returning integrator needs to know about what changed since they last built against the platform. Filter with the tag buttons: API marks a change to the reference surface, Behavior a change to how an endpoint acts, Docs a guide or clarification. Breaking means you must act; Additive means nothing you already built will break. One timeline, newest first. Entries tagged API are generated automatically from a diff of the published OpenAPI contract — they appear here the moment a contract change deploys, with each operation linking to its page in the API reference. Guide and behavior notes are authored alongside the change that ships them. Both kinds share a single reverse-chronological list, so the most recent change is always at the top.
​
DocsAdditive
A guide for connecting a Lovable-generated storefront
A new guide, Connect a Lovable storefront, covers wiring a storefront generated from a written prompt to the platform: which of your three credentials may ever reach browser code, the two browser-safe reads and the exact-origin allowlist that governs them, both ways into the flow, and a reusable prompt that holds no credential.It is explicit about what you can build against now and what depends on your brand’s configuration. The browser read needs two things switched on for your brand — a publishable key and a registered origin — and until both are in place every cross-origin call is refused, whatever credential it carries. The questions-first entry is a server-side path end to end: your page can never call those endpoints itself. And the guide repeats the rule that costs integrators the most: there is no redirect back to your storefront after payment, so a payment outcome is read with GET /v1/payments/{order_ref}/status or delivered by webhook — never inferred from the browser.One correction of terminology worth reading if you have built against another payment tool: on this platform a pk_ key is a server secret, and the browser-safe credential is the publishable brand key beginning pub_test_ or pub_live_.
​
DocsBreaking
The enrollment status read has documented outcomes other than a status
No endpoint changed — what we told you about one did. The guides said an enrollment id was readable for its status from the moment it existed. The contract declares more outcomes than that for GET /v1/journeys/{journey_id}/status: besides the 400/401/404 refusals, it can return 422 with the type https://purple.md/problems/journey-status-pending — a typed “no status yet” response for an enrollment that is yours — and 503 when the status source is unavailable. Code that treats any non-200 from that read as a failed call, or as a missing enrollment, needs a branch for it.The patient flow now documents those outcomes and how they differ: branch on the type, and read a 503 as “the read did not succeed” rather than as a statement about the patient. The quickstart, how it works, the checkout door, the identity handoff and identifiers and error types are corrected to match. The identity handoff also no longer implies that verification produces a status change of its own — it does not, and never did.
​
APIAdditive
commit ae1613d
Changed
​
APIAdditive
commit b459b2b
Added
​
APIAdditive
commit 85c6665
Added
​
APIAdditive
commit a2a7fa8
Added
​
APIAdditive
commit 9016094
Changed
​
APIAdditive
commit aa30010
Changed
​
APIAdditive
commit 9f26db7
Added
​
APIAdditive
commit f043001
Changed
​
APIBreaking
commit e8f344c
Changed
​
APIBreaking
commit 4c1ff5b
Changed
​
APIAdditive
commit ea56e47
Changed
​
DocsAdditive
Three new guides + guide fixes
Three new guides join the Integrate section: Pricing — set the price your patients pay, what the price floor means, and how the hosted checkout resolves your stored price; The patient flow — the enrollment stages end-to-end, the eleven-value public status vocabulary, and where the payment step sits; and Login URLs and domains — building the sign-in link, the member portal origin, and the self-serve custom-domain ladder. The welcome kit now lists your API base URL and member portal origin, and the base-URL wording across the guides is aligned: the test-environment base is issued with your key.
​
APIBreaking
commit 82f9057
AddedRemoved
  • GET /v1/journeys/{journey_id}/status
​
APIAdditive
commit 7662829
Added
​
APIAdditive
commit 0a3a895
Changed
​
DocsAdditive
How questions work
A new guide, How questions work, explains the model behind the question endpoints: facts and the shared catalog, controls, the line between your screening questions and the medical intake, and how the engine serves an intake one question at a time. It deep-links every question-authoring operation on the public reference.
​
APIAdditive
commit ba74887
Added
  • POST /v1/account/brands/{brand_id}/offerings — enableAccountOffering
  • PUT /v1/account/offerings/{ref}/merchandising — setAccountOfferingMerchandising
​
APIAdditive
commit 4b3fd94
Added
  • GET /v1/account/brands/{brand_id}/domains/{kind} — getAccountBrandDomain
  • GET /v1/account/brands/{brand_id}/domains — listAccountBrandDomains
  • DELETE /v1/account/brands/{brand_id}/domains/{kind} — removeAccountBrandDomain
  • PUT /v1/account/brands/{brand_id}/domains/{kind} — setAccountBrandDomain
  • POST /v1/account/brands/{brand_id}/domains/{kind}/verify — verifyAccountBrandDomain
​
APIAdditive
commit 970046f
Added
  • PUT /v1/account/brands/{brand_id}/config — setAccountBrandDisplay
Changed
  • GET /v1/instrument/resolve — resolveInstrument: parameter added: query:phase; response added: 400
​
APIAdditive
Brand configuration
The display identity (name, logo, theme tokens, support email) is now a self-serve write with your own API key at PUT /v1/account/brands/{brand_id}/config, with the matching readback on GET. The token reference and the copy wording wall are documented in the brand configuration guide.
​
DocsAdditive
docs-pipeline
This “API changes” page is now live, with automatic reference-change entries generated from the published contract on every deploy.