> ## 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. # Check whether your brand is ready to sell > Reports whether one of your brands can actually sell yet, and what is still outstanding if it cannot. Two levels: brand-wide checks covering your payment account and your checkout consent documents, and one row per offering you have enabled carrying the platform's live verdict plus the per-check report behind it. Every outstanding item says what has to happen and who does it, so a step only Purple operations can complete is never handed to you as yours to do. Some checks cannot be answered by this endpoint; those are reported as unverifiable rather than guessed, and unverifiable is never a pass. Read source_readable before you read an empty offering list: false means the setup could not be read just now. You may ask about your own brands only; any other brand is not found. This read reports configuration state and changes nothing. CALLING IT FROM A BROWSER: a web page may call this read directly. Present a publishable brand key — sent as `Authorization: Bearer pub_live_…`, or `pub_test_…` outside production — which is minted for a single brand, is read-only, and is meant to be shipped in page source. The key reaches only the operations its allowlist names: today that is this read and that brand's storefront price read, and nothing else — every other operation, and every write, is refused. Because it is minted for one brand it may only ask about that brand — any other brand, a sibling brand on your own account included, answers the same not found as a brand that does not exist, and the refusal never tells you which of those it was. A cross-origin page must also have its exact origin registered on that brand's browser-origin allowlist, so publishing the key does not by itself open the read to any site. The server path is unchanged — call this endpoint from your own server with your secret API key exactly as before, and never put that secret key in page source. ## OpenAPI ````yaml /openapi/public-openapi.json get /v1/account/brands/{brand_id}/readiness openapi: 3.1.0 info: title: Purple API version: 0.0.0 servers: - url: https://api.dev.purplelabelmd.com security: [] tags: - description: Sign a patient in and out and manage the browser session. name: Sessions & authentication - description: Run the server-driven intake questionnaire question by question. name: Intake - description: Address autocomplete for the intake flow. name: Addresses - description: Read the public status of a patient's enrollment. name: Enrollment - description: Track a client's onboarding progress. name: Onboarding - description: Read back the platform configuration stored for your brand. name: Brand configuration - description: Enable offerings for your brand and set their display copy. name: Offering configuration - description: Start and track payments for an order. name: Payments - description: Subscribe to platform events and manage delivery endpoints. name: Webhooks paths: /v1/account/brands/{brand_id}/readiness: get: tags: - Onboarding summary: Check whether your brand is ready to sell description: >- Reports whether one of your brands can actually sell yet, and what is still outstanding if it cannot. Two levels: brand-wide checks covering your payment account and your checkout consent documents, and one row per offering you have enabled carrying the platform's live verdict plus the per-check report behind it. Every outstanding item says what has to happen and who does it, so a step only Purple operations can complete is never handed to you as yours to do. Some checks cannot be answered by this endpoint; those are reported as unverifiable rather than guessed, and unverifiable is never a pass. Read source_readable before you read an empty offering list: false means the setup could not be read just now. You may ask about your own brands only; any other brand is not found. This read reports configuration state and changes nothing. CALLING IT FROM A BROWSER: a web page may call this read directly. Present a publishable brand key — sent as `Authorization: Bearer pub_live_…`, or `pub_test_…` outside production — which is minted for a single brand, is read-only, and is meant to be shipped in page source. The key reaches only the operations its allowlist names: today that is this read and that brand's storefront price read, and nothing else — every other operation, and every write, is refused. Because it is minted for one brand it may only ask about that brand — any other brand, a sibling brand on your own account included, answers the same not found as a brand that does not exist, and the refusal never tells you which of those it was. A cross-origin page must also have its exact origin registered on that brand's browser-origin allowlist, so publishing the key does not by itself open the read to any site. The server path is unchanged — call this endpoint from your own server with your secret API key exactly as before, and never put that secret key in page source. operationId: getCommerceAccountBrandReadiness parameters: - description: >- the brand to check. Must be one of your own brands; any other brand is not found (404, never 403 — existence is never revealed across accounts). in: path name: brand_id required: true schema: type: string - description: the resolved account, set by the gateway. in: header name: X-Client-Id required: true schema: minLength: 1 type: string - description: the brands the resolved account owns, set by the gateway. in: header name: X-Client-Brand-Ids required: true schema: minLength: 1 type: string responses: '200': content: application/json: schema: properties: data: $ref: '#/components/schemas/CommerceBrandReadiness' required: - data type: object description: the brand's readiness report '400': content: application/problem+json: schema: $ref: '#/components/schemas/CommerceProblem' description: malformed owned-brand header — RFC 7807 '401': content: application/problem+json: schema: $ref: '#/components/schemas/CommerceProblem' description: >- Unauthenticated — an unknown or revoked API key resolves nothing and returns a single opaque error body, with no way to probe whether a key is valid — RFC 7807 '404': content: application/problem+json: schema: $ref: '#/components/schemas/CommerceProblem' description: >- not one of your brands — an unknown brand, a brand belonging to another account, and a malformed brand id are ONE indistinguishable refusal (404, never 403) — RFC 7807 '405': content: application/problem+json: schema: $ref: '#/components/schemas/CommerceProblem' description: method not allowed — this endpoint is read-only — RFC 7807 security: - apiKey: [] - publishableKey: [] components: schemas: CommerceBrandReadiness: additionalProperties: false description: >- Whether one of your brands is ready to sell, and what is outstanding if it is not. checks covers the brand as a whole; offerings covers each offering you have enabled. Read source_readable first: false means the platform could not read your offering setup just now, so an empty rows list means "we could not look", never "nothing is outstanding". properties: brand_id: pattern: ^brd_[A-Za-z0-9][A-Za-z0-9_-]*$ type: string checks: description: >- brand-wide readiness rows — your payment account and your checkout consent documents. items: $ref: '#/components/schemas/CommerceReadinessCheckRow' type: array offerings: additionalProperties: false properties: rows: items: $ref: '#/components/schemas/CommerceReadinessOffering' type: array source_readable: description: >- whether the platform could read your offering setup for this request. When false, rows is empty because the read did not answer — not because nothing is outstanding. type: boolean required: - source_readable - rows type: object required: - brand_id - checks - offerings type: object CommerceProblem: description: RFC 7807 problem document (api-style-guide) properties: detail: type: string status: type: integer title: type: string type: type: string required: - type - title - status type: object CommerceReadinessCheckRow: additionalProperties: false description: >- One readiness check. kind tells you how much the platform actually knows: performed means the check ran against real data and result is its answer; unverifiable means the check could not be run here, so it is neither a pass nor a fail and must not be read as either; named_pending means the check exists but its rules are not settled yet, and blocking says whether it holds the offering back today. properties: blocking: description: present only when kind is named_pending. type: boolean check: description: the check's stable identifier. type: string detail: description: >- plain-language explanation. When something is outstanding this names what has to happen and who does it, so a step nobody on your side can perform is never presented as yours. type: string kind: description: performed, unverifiable, or named_pending. type: string result: description: pass or fail — present only when kind is performed. type: string required: - check - kind - detail type: object CommerceReadinessOffering: additionalProperties: false description: >- One of your brand's enabled offerings, with the platform's live verdict on whether it can be sold and the per-check report behind that verdict. properties: checks: items: $ref: '#/components/schemas/CommerceReadinessCheckRow' type: array offering_ref: description: the offering's code. type: string status: description: >- the platform's live verdict for this offering — active means it can be sold now; anything else means it cannot yet, and the checks below say why. type: string required: - offering_ref - status - checks type: object securitySchemes: apiKey: description: 'Per-client API key (M2M). Presented as `Authorization: Bearer `.' scheme: bearer type: http publishableKey: description: >- Brand-scoped, read-only publishable key, safe to ship in a website. Presented as `Authorization: Bearer ` with the `pub_live_`/`pub_test_` prefix. It is minted for ONE brand and reaches only the two brand reads that declare it; every other operation, and every write, is refused. Cross-origin browser use additionally requires the page's exact origin on the brand's browser-origin allowlist. scheme: bearer type: http ````