Account API
Account API
Use the Account API to allocate independent API Keys, credits, and access limits. Availability depends on the current account. These APIs are enabled when GET /dashboard/status returns manage: true.
export BASE_URL="https://api.xairouter.com"
export API_KEY="sk-Xvs..."Endpoints
| Method and path | Description |
|---|---|
POST /x-users | Create an account |
GET /x-users | List direct accounts |
GET /x-users/{identifier} | Get a direct account |
GET /x-dna | List all descendant accounts |
GET /x-dna/{identifier} | Get a descendant account |
PUT /x-users/{identifier} | Update an account |
DELETE /x-users/{identifier} | Delete an account |
POST /x-users/batch-credit | Adjust credits in bulk |
POST /x-self | Rotate the current API Key |
Use the account ID for identifier when possible. Account names and email addresses are also accepted. All reads and writes are restricted to accounts manageable by the current caller.
See the Usage API for current-account and descendant-account usage queries.
Create an account
POST /x-usersMinimal request:
{
"Email": "[email protected]",
"CreditGranted": 20
}Name is optional and is generated when omitted. Common fields:
| Field | Type | Description |
|---|---|---|
Name | string | Optional; 4–63 characters with at least one letter |
Email | string | Required; valid and not already in use |
CreditGranted | number | Initial credit |
Alias | string | Display name |
BillingEmail | string | Billing notification address |
Rates | number | Price multiplier; cannot be lower than the caller's multiplier |
RPM / RPH / RPD | integer | Per-minute, hourly, and calendar-day request limits |
TPM / TPH / TPD | integer | Per-minute, hourly, and calendar-day token limits |
DailyLimit | number | Daily hard spending limit |
HardLimit / SoftLimit | number | Monthly hard limit and warning threshold |
ModelLimits | object | Per-model rate limits |
Per-model limit example:
{
"ModelLimits": {
"gpt-5*": {
"rpm": 60,
"rph": 1000,
"rpd": 5000,
"tpm": 200000,
"tph": 2000000,
"tpd": 10000000
}
}
}RPD and TPD reset on the server's business date; they are not rolling 24-hour windows.
Query accounts
curl "$BASE_URL/x-users?page=1&size=20" \
-H "Authorization: Bearer $API_KEY"Common query parameters:
| Parameter | Description |
|---|---|
id | Account ID |
name | Account name |
email | Email address |
level | Level |
page / size | Pagination |
order | Sort order |
Pagination metadata is returned in response headers:
X-Total-Count
X-Total-Pages
X-Page
X-Per-Page/x-users returns direct accounts only. Use /x-dna when you need every descendant account.
Update an account
PUT /x-users/{identifier}curl -X PUT "$BASE_URL/x-users/42" \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{
"CreditGranted": 10,
"RPM": 120,
"TPD": 5000000,
"AllowModels": "gpt-5*"
}'A positive CreditGranted adds credit; a negative value deducts it. When updating credit, include Days to set the validity period of the newly added credit. Other updatable fields mostly match creation fields. Permissions cannot exceed the caller's own available scope.
For updates, AllowIPs, AllowModels, and Resources use comma-separated strings. Model allowlists support wildcards. For example:
{
"AllowIPs": "203.0.113.10,203.0.113.11",
"AllowModels": "gpt-5*,text-embedding-*",
"Resources": "/v1/chat/completions,/v1/responses"
}Delete an account
curl -X DELETE "$BASE_URL/x-users/42" \
-H "Authorization: Bearer $API_KEY"Confirm the account is no longer in use before deleting it. Its API Key becomes invalid immediately, and remaining credit is returned according to server rules.
Bulk credit adjustment
POST /x-users/batch-credit{
"IDs": [42, 43, 44],
"CreditGranted": 10,
"Days": 30,
"DryRun": true
}CreditGrantedmust be non-zero; positive values add credit and negative values deduct it.- Preview with
DryRun: true, then submit withfalseto apply. - Each result is marked
appliedorskipped; the response also summarizes parent and child credit changes.
Rotate the current API Key
POST /x-self{
"confirm": "2026-07-18-ROTATE-SELF"
}The date in confirm must match the server's current date. The new Key is shown once and the old Key becomes invalid immediately, so prepare a secure update workflow first.