Skip to main content
PUT
Choose a custom domain for a kind (client self-serve)

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 custom domains to view or manage (must match X-Brand-Id).

Pattern: ^brd_[A-Za-z0-9][A-Za-z0-9_-]*$
kind
enum<string>
required

the custom-domain kind — login (the auth domain) or member (the member-portal domain).

Available options:
login,
member

Body

application/json

Choose a custom domain for a kind. The only field is the hostname you want to use; the brand is the one your API key owns (resolved from X-Brand-Id, never taken from the body), so a request-supplied brand or provider id is structurally inert. Any other field is refused with a 400 that names it — a field this operation does not accept is never silently ignored.

hostname
string
required

the custom hostname to register (e.g. login.example.com).

Minimum string length: 1

Response

the registered row + its CNAME paste-row (state cname_rendered)

data
object
required

One custom-domain row as the registry holds it: the brand, the kind (login | member), the hostname, its provisioning state, who owns and who bound the host, timestamps, and the CNAME paste-row to add to your DNS. The row never carries a secret nor the provider's internal domain id. An absent row (a kind you have not registered) is the shared-domain default.