switching clears the token & responses
No token
39

Configure the self-registration policy

Spans both profiles. Read and set the single global policy that governs which sign-up methods the public profile offers for every tenant. The write lives here on the control plane; the public profile only reads it. Requires iam-platform-admin.

  1. GET /v1/admin/registration-policy → read active allowedMethods + combinationMode
  2. PUT /v1/admin/registration-policy → set the policy (step-up; audits registration_policy_changed)
  3. GET /v1/auth/registration-policy (public profile) → the sign-up UI reads the now-current policy
GET/v1/admin/registration-policyadminRead registration policy

A single global setting (no tenant scope) — self-registration creates the tenant, so there is no tenant to scope it to.

ℹ︎Field guide — what each value means & where it comes fromno inputs

No request body, path params, or query params. A bodyless GET that returns the single global self-registration policy. Still requires platform-admin authorization (role iam-platform-admin); the tester/gateway supply Authorization and x-gateway-context for you. No Idempotency-Key needed (read-only).

Bearer token
→ GET https://api.kerja.team/v1/admin/registration-policy
↩︎Response guide — what comes back & what each value means4 fields

200 OK returning the { data } envelope with the active global self-registration policy; no notable response headers (no Set-Cookie, no Cache-Control: no-store).

dataobjectalways
The active global RegistrationPolicy object describing which sign-up methods the public profile offers and how they combine.
data.allowedMethods[]arrayalways
Non-empty array of the sign-up methods currently enabled on the public profile. Each item is one of the allowed method enums; the client renders these as the available registration entrypoints.
  • email — Email-based self-registration is offered on the public profile.
  • phone — Phone-based self-registration is offered on the public profile.
data.combinationModeenumalways
Determines how multiple allowedMethods combine during sign-up; the client uses this to decide whether a user picks one method or must satisfy all.
  • link — Methods are alternatives — the user signs up with any one of the allowedMethods.
  • atomic — Methods are combined — the user must provide all of the allowedMethods together in a single sign-up.
data.updatedAtISO-8601always
Timestamp of when the policy was last changed (e.g. via PUT /v1/admin/registration-policy). Used to display when the policy was last modified.
PUT/v1/admin/registration-policyadminSet registration policy (step-up)

Step-up required. allowedMethods must be a non-empty, duplicate-free subset of { email, phone }; combinationMode is link or atomic. Only gates sign-up — never login, and never strips users who already hold a credential.

⛓ Needs an out-of-band value?
Request body (JSON)
ℹ︎Field guide — what each value means & where it comes from5 fields

Sets the active self-registration policy (platform-admin, control-plane). Needs Authorization/x-gateway-context (handled by tester+gateway) plus a step-up factor in the body — supply EITHER stepUp.password OR stepUp.recoveryCode. Body is .strict() (unknown fields rejected). No path/query params or required custom headers.

allowedMethodsbodystring[]requiredyou choose
You choose which sign-up channels are enabled. Non-empty array, no duplicates; each value must be one of the allowed methods. Controls which entrypoints the public sign-up surface offers.
  • email — Permits self-registration via email address.
  • phone — Permits self-registration via phone number.
combinationModebodyenumrequiredyou choose
You pick how the allowed methods combine when more than one is enabled.
  • link — Methods are treated as separate, linkable sign-up paths.
  • atomic — Methods must be provided together as a single atomic registration.
stepUpbodyobjectrequiredyou choose
Step-up re-authentication wrapper, verified before the mutation. Must contain at least one of password or recoveryCode.
stepUp.passwordbodystringconditionalyou choose
Your current account password (1-1024 chars). Required unless you instead supply stepUp.recoveryCode; at least one of the two must be present. Used to satisfy step-up re-auth before changing the policy.
stepUp.recoveryCodebodystringconditionalauthenticator
A one-time recovery code from your MFA authenticator setup (1-128 chars), pasted in. Required unless you instead supply stepUp.password; at least one of the two must be present. Used to satisfy step-up re-auth before changing the policy.
Bearer token
→ PUT https://api.kerja.team/v1/admin/registration-policy
↩︎Response guide — what comes back & what each value means3 fields

200 OK; body is the { data } envelope wrapping the updated RegistrationPolicy object (no special response headers — no Set-Cookie/Cache-Control noted).

data.allowedMethods[]enumalways
The self-registration methods now active across all tenants' public sign-up surfaces; reflects the value just written. Non-empty, no duplicates.
  • email — Email-based self-registration is permitted.
  • phone — Phone-based self-registration is permitted.
data.combinationModeenumalways
How the allowed methods combine when more than one is enabled; reflects the value just written.
  • link — Methods are offered as separate, linkable sign-up options.
  • atomic — Methods must be provided together as a single atomic registration.
data.updatedAtISO-8601always
Server timestamp when the global policy row was last updated by this write. Use to confirm the change took effect and for display/audit correlation.
GET/v1/auth/registration-policypublicPublic sign-up reads the policy

The public profile (scenario 1) reads the now-current policy to render the right form. This is the read side of the cross-profile registration-policy bridge.

ℹ︎Field guide — what each value means & where it comes fromno inputs

No request body, path params, query params, or required headers. This is a public, unauthenticated, read-only endpoint — no Authorization or x-gateway-context is required either. It returns the active self-registration policy (allowedMethods and combinationMode) so the sign-up UI can render the correct form.

→ GET https://api.kerja.team/v1/auth/registration-policy
↩︎Response guide — what comes back & what each value means4 fields

200 OK returning the standard { data } envelope; body is the active self-registration policy (no secrets, no user data). Response header Cache-Control: public, max-age=30 (lightly cacheable). If the policy row is missing it defaults to { allowedMethods: ["email"], combinationMode: "link" }.

dataobjectalways
Envelope wrapper holding the active self-registration policy the unauthenticated sign-up UI uses to render the correct form.
data.allowedMethodsarrayalways
The identifier methods the sign-up form may offer; a subset of ["email","phone"]. The client renders one input per listed method. Defaults to ["email"] when the policy row is missing.
data.allowedMethods[]enumalways
An allowed registration identifier method. Each value tells the UI which credential input to render.
  • email — Sign-up may use an email address (render the email field).
  • phone — Sign-up may use a phone number (render the phone field / OTP flow).
data.combinationModeenumalways
How the allowed methods combine during sign-up; drives whether the form collects one identifier or both at once. Defaults to "link" when the policy row is missing.
  • link — Default — register with a single method now and add the second method later under /v1/me.
  • atomic — A single register call must carry both methods together.