Provision accounts for your customers

What this is, and when to use it

The developer platform lets you provision full Ringside accounts for your end customers programmatically. Each provisioned account is a real account: its own username and password for the web UI, its own per-user vault, and its own ko_ API key, and it can create its own Brain. This is the right tool when each of your customers needs genuine isolation and their own credentials, for example a per-tenant deploy that stores its own ko_ key and creates its own Brain.

Become a developer

Provisioning is gated behind developer enrollment, which is self-serve and auto-approved. From your Ringside dashboard at /app/developer, accept the Developer Addendum (it covers your responsibility for the accounts you create and the fact that money moves from your wallet to theirs). Enrolment flips is_developer on your account and creates your developer profile. Enrolment is orthogonal to your account type, so any account can become a developer.

Then mint your provisioning key. You get exactly one active key (rotate = revoke and reissue). It is an rsk_ key, distinct from a tenant ko_ key: an rsk_ key creates accounts, a ko_ key authenticates one. The full key is shown once on creation, hashed at rest thereafter.

Create an account

Authenticate with your provisioning key (Authorization: Bearer rsk_...). The body needs an email, a username (3-20 chars, alphanumeric or underscore), a password (8-256 chars) and a funding mode. vault_password is optional and defaults to the login password.

curl https://api.fightclub.pro/v1/accounts \
  -H "Authorization: Bearer rsk_REDACTED" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "dev@customer.com",
    "username": "customer_acme",
    "password": "a-strong-password",
    "funding": "grant",
    "amount_usd": 25.0
  }'

The four funding modes

Money always moves from you to the customer. Every transfer is atomic and insufficient-funds checked. There is no platform-imposed spend cap on linked accounts, so bounding a linked customer's burn is yours to manage.

The account limit

Each developer may have up to 10 active provisioned accounts. Closing an account frees a slot, so you can churn customers without a ticket. Over the limit, POST /v1/accounts returns 403 cap_reached. To raise the ceiling, open a support ticket; an admin sets it per developer, up to 10,000 active accounts, so a high-volume integrator can be lifted well past the default. There is no self-serve bulk path, so build the raise into your onboarding plan.

You are a mini-admin over the accounts you create: from /app/developer you can list them with their balance and spend, mint vouchers, and close an account. Closing it blocks its login and immediately revokes its ko_ tokens.

Errors

Manage accounts from code

The full lifecycle is available with the same rsk_ provisioning key, so an integrator can onboard and offboard tenants entirely from code, no dashboard required.

Region and data residency

Provisioning an account does not make it EU-resident. Residency is chosen per call by pinning a fully-qualified model ref with an @eu, @eu-bedrock or @eu-vertex suffix; there is no account-wide region default. An account intended for EU-only processing must send the EU-suffixed ref on every call, including its Brain embedding and recall calls. See Regions and data residency for the exact suffixes and which providers back each.

A full per-customer onboarding flow

1. 01Provision the account with funding: "grant" (or "linked" if you carry their usage). Capture the returned account.id and the one-time api_key.
2. 02Store the ko_ api_key in that customer's vault or secret store. It is their credential, not yours.
3. 03Create the customer's Brain with their key: POST /v1/brains using Authorization: Bearer <their ko_ key>.
4. 04Hand the returned message to the customer so they can sign in and, if self-funded, top up.
5. 05When the customer leaves, close the account from your dashboard to free a slot and revoke their key.