Skip to main content
PUT
Set your brand's display identity (client self-serve, configure plane)

Authorizations

Authorization
string
header
required

Per-client API key (M2M). Presented as Authorization: Bearer <key>.

Headers

X-Brand-Id
string
required

Opaque brand id (brd_...). Validated to belong to the resolved client (§2).

Pattern: ^brd_[A-Za-z0-9][A-Za-z0-9_-]*$
Idempotency-Key
string

Accepted on mutations; carried in trusted context, enforced in a later WI.

Path Parameters

brand_id
string
required

the brand whose display identity to set (must match X-Brand-Id).

Pattern: ^brd_[A-Za-z0-9][A-Za-z0-9_-]*$

Body

application/json

The client self-serve display-write payload. The ONLY field is display: the client sets or updates its own brand display-identity block with its own API key. There is deliberately no theme, redirect-allowlist, or charge-topology field — those stay operator-controlled; a client cannot set them here (any such key is barred by additionalProperties:false and, at runtime, is never read). The block is merged onto the existing configuration and validated UNCHANGED by the brand-config validator (the wording wall: a copy key is refused 422, issues verbatim).

display
object
required

the per-brand display-identity block to set or update (merged onto the existing config).

Response

the stored configuration (the same projection you read back)

data
object
required

A brand's platform configuration as the platform holds it — clinically inert BY CONSTRUCTION (the validator enforces a top-level allowlist + a recursive clinical-shaped-key denylist). The client readback and the operator view return this EXACT shape (one projection, no drift). Presentation and commercial reach only; never a clinical field. additionalProperties:false mirrors the validator's top-level allowlist.