Enterprise Account Management

Enterprise accounts help teams isolate model access and usage reporting by department, project, or customer. The account hierarchy has two levels: an enterprise main account for governance, permissions, and auditing, and enterprise sub-accounts for actual API usage.

Each enterprise sub-account has its own console login and API key management permissions. The previous workflow, where a main account created keys and delegated them to sub-accounts, is no longer the primary enterprise workflow.

Account Roles

Capability	Main account	Sub-account
Sign in to the console	✓	✓
Create, edit, enable, disable, and delete sub-accounts	✓	✗
Reset sub-account passwords	✓	✗
Configure administrator notification contacts	✓	✗
Configure allowed model IDs	✓	✗
Create, delete, copy, or reveal full API keys	✗	✓
View masked API key metadata	✓	✓
Adjust API key model limits	Sub-account keys only	Own keys
Manage API key egress IP allowlists	✗	✓
View usage for all enterprise sub-accounts	✓	✗
View own usage	✗	✓
View enterprise risk alerts	✓	✗
Configure own daily usage alert	✗	✓

The main account does not create or hold API keys for business traffic and cannot delete, copy, or reveal the full secret of a sub-account key. It can view masked key metadata and adjust model limits for sub-account keys. Sub-accounts handle API calls, while their usage remains part of the enterprise account's reporting.

Console Navigation

Enterprise main accounts can use these pages:

• Enterprise Account Management: create and manage sub-accounts, administrator contacts, and model permissions.
• Enterprise Billing: view usage summaries and period details for all sub-accounts.
• Risk Alerts: review password, API key egress IP allowlist, and administrator contact risks.

Enterprise sub-accounts can use these pages:

• Enterprise Account Management: view recent usage and configure a daily usage alert.
• Enterprise Billing: view their own usage by date and reporting period.
• API Keys: manage their own keys, model limits, and egress IP allowlists.

Create an Enterprise Sub-Account

After signing in as an enterprise main account, open Enterprise Account Management and create a sub-account. Configure the following fields:

• Username: the unique sign-in name, up to 20 characters.
• Initial password: used for the first sign-in, between 8 and 20 characters.
• Display name: optional, defaults to the username, up to 20 characters.
• Account email: optional account-profile information for the sub-account. It is independent of administrator notification emails.
• Sub-account administrator emails: enter at least two distinct, valid email addresses. More addresses can be added. These are notification contacts for this sub-account; they are not sign-in accounts and receive no login or management permissions.
• Allowed model IDs: select at least one exact model ID. Models can be selected individually or in GPT, Claude, Gemini, and other family groups.

The system may limit how many sub-accounts a main account can create. If the limit is reached, remove an unused sub-account or contact the platform for assistance.

After creation, the sub-account signs in with its username and initial password. It must change the password before using other features.

Administrator Notification Contacts

The enterprise main account configures multiple sub-account administrator emails for each enterprise sub-account. These addresses receive security, risk, usage, and sensitive-operation notifications for that sub-account.

Keep the following behavior in mind:

• Each sub-account requires at least two distinct, reachable administrator email addresses and can have more.
• An administrator email is only a notification contact. It does not need to belong to a registered sub-account and receives no console, API, or account-management permissions.
• Administrator emails are maintained separately for each sub-account. Notifications for one sub-account go only to its configured contacts.
• Duplicate addresses are treated as one contact, and invalid addresses cannot be saved.
• Update the sub-account's administrator email list promptly when contacts change or an address becomes unavailable.

First Sign-In and Password Management

An enterprise sub-account must change its password after the first sign-in or after the main account resets it. Until the password is changed, only account profile and password verification operations are available.

The main account can reset a password from the sub-account list. The reset password is still temporary and must be changed at the sub-account's next sign-in.

The following conditions are reported as password risks:

• The initial or reset password is still in use.
• No valid password change time is recorded.
• The password has not been changed for more than two months.

Sub-Account Status and Deletion

The enterprise main account can enable or disable a sub-account:

• Disabled: the sub-account cannot sign in, and API keys assigned to it cannot be used normally.
• Enabled: restores sign-in and API access that complies with the account's permission policy.

The main account can also update a sub-account's display name, account email, administrator email list, and allowed model IDs.

Deleting a sub-account is irreversible. The account can no longer sign in, and its API keys, enterprise policies, and related enterprise account data are removed. Migrate production workloads and retain any required audit records before deletion.

Exact Model Permissions

The enterprise main account configures exact model IDs for each sub-account, not only broad model families such as GPT, Claude, or Gemini.

The model selector groups IDs by family to make bulk selection easier, but the stored and enforced policy is a list of exact IDs. For example, allowing claude-sonnet-4 does not automatically allow every other Claude model.

Model permissions follow these rules:

• A sub-account can call only the model IDs selected by the main account.
• The main account can view masked metadata for sub-account keys and adjust each key's model limits from the API key list.
• A key-level model limit cannot expand the sub-account's permissions. Every model allowed by the key must be within the sub-account's allowed model IDs.
• If a sub-account enables key-level model limits, every selected model must be within the sub-account's allowed list.
• The sub-account policy still applies when an API key has no separate model limit.
• The selectable model list may change when the main account's own access changes.

API Keys and Egress IP Allowlists

Enterprise sub-accounts can create, view, edit, delete, and copy their own API keys. The main account cannot create, delete, or copy a key on behalf of a sub-account and cannot reveal its full secret. It can only view masked metadata and adjust model limits for sub-account keys.

Configure an egress IP allowlist for every production API key whenever possible. Enabled keys without an allowlist are included in enterprise risk alerts.

The following actions trigger enterprise sensitive-operation notifications:

• Creating or deleting an API key.
• Deleting API keys in a batch.
• Updating an egress IP allowlist.
• Changing model permissions or key-level model limits.
• Resetting a sub-account password.
• Updating administrator contacts.

Notification emails never include a full API key.

Enterprise Billing and Usage Details

The enterprise main account can view usage for every sub-account, while a sub-account can view only its own usage. Enterprise billing supports:

• Daily or monthly reporting.
• A custom date range.
• Total usage, request count, Prompt Tokens, Completion Tokens, and Total Tokens.
• Searching sub-accounts by username or display name from the main account view.
• Sorting by usage or account name.
• Expanding an account row to inspect each date or month's details.
• Exporting the current reporting range to CSV.

An enterprise main account can also use its console-generated bill-... billing read-only token with GET /api/usage/enterprise to retrieve billing data for all direct enterprise sub-accounts. The token grants enterprise billing read access only.

The usage column can be switched between these categories:

1. Total usage
2. GPT
3. Claude
4. Gemini
5. Seedance
6. HappyHorse
7. Suno
8. Doubao
9. MiniMax
10. Image2
11. MJ
12. Vidu
13. Qwen
14. GLM
15. Kling
16. Other

GPT, Claude, Gemini, and Seedance appear first, followed by the remaining categories. Usage that cannot be classified into one of the listed categories is included in Other.

Daily and monthly period boundaries default to UTC+0; callers can provide another timezone_offset when using the enterprise billing API. The enterprise account page for a sub-account shows its most recent 31-day total, daily details, and monthly details by default.

Daily Usage Alerts

An enterprise sub-account can configure its own daily usage alert:

• Enable the alert and enter a threshold greater than zero. The console labels this value in quota units.
• Usage is accumulated by UTC+8 calendar day and checked by a periodic background task.
• After the threshold is reached, the administrator emails configured for that sub-account receive a notification. A successfully sent alert is not repeated for the same sub-account on the same day.
• The background task checks once per hour. After the threshold is reached, the notification is normally sent within one hour, although email delivery may add further delay.
• Alerts are for monitoring and governance only. They do not disable accounts, delete keys, or block requests.

Risk Alerts

Enterprise main accounts can review these conditions for every sub-account on the Risk Alerts page:

• Whether the initial password is still in use or the password has not been changed for more than two months.
• The number of enabled API keys without an egress IP allowlist.
• The number of active administrator contacts. Fewer than two contacts are reported as a risk.

Risk scans and email notifications are performed by periodic background tasks, so the page and notification state may not update immediately after a change. Main account administrators should review the page regularly and ask the relevant owners to update passwords, configure IP allowlists, or add administrator contacts.

Recommended Practices

• Configure at least two distinct, valid administrator email addresses for every sub-account and keep them current as contacts change.
• Split sub-accounts by department, project, or external customer instead of sharing one sign-in broadly.
• Configure an egress IP allowlist for every production API key and allow only the exact model IDs required by the workload.
• Update account emails, administrator contacts, and model permissions when ownership changes.
• Confirm that production keys have been migrated before disabling or deleting a sub-account.
• Review enterprise billing, exported CSV audit records, and risk alerts regularly.