Teams and multiple projects on one account: one key per member, project and environment
An account has no member sub-accounts, so teams split access and spend with API keys — one per member, project and environment, each with its own cap, expiry, model limits, IP allowlist and group. Usage per key in Logs and on the Dashboard, CSV exports for finance, access tokens for scripts and two-step verification for the owner.
A Tutujin API account has no member sub-accounts; a team divides access and spend with API keys. Give each member, project and environment its own key, and set a spending cap, expiry, model limits, an IP allowlist and a group on each one. Every call is recorded under the key that made it, so Logs and the Dashboard break usage down by key, and a CSV export goes straight to finance. Only the account owner signs in to the console, with two-step verification on and an eye on the security log; scripts that check balance or usage use scoped personal access tokens rather than the account password.
How to split keys
Split by who uses the key, for which project and in which environment, with one purpose per key:
| Dimension | Example names | Suggested settings |
|---|---|---|
| Environment | support-bot-prod, support-bot-staging | An IP allowlist on production keys; a low cap on test keys |
| Project or product line | knowledge-base-prod, marketing-copy-prod | One cap per project, and model limits listing only the models the project uses |
| A member's development key | alice-dev | A small cap and an expiry; disable it when the project ends |
| Contractors and pilots | contractor-website-revamp | Expiry plus a cap, so it stops on its own |
Names show up in Logs and in exported CSVs, so include the project and environment and you can tell at month end where each charge belongs. Add key can create several keys at once (up to 100), adding a random suffix to every name after the first, which is handy when onboarding a team.
What each key controls
Set these when you create or edit a key on the API keys page; changes apply immediately:
| Setting | What it does | When the limit is hit |
|---|---|---|
| Quota cap | The most this key can spend in total; or choose Unlimited | 401 for this key; other keys are unaffected |
| Expiry | The key stops working after this time; quick picks from 1 hour to 1 year, or a date | 401 |
| Model limits | Only the selected models can be called | 403 |
| IP allowlist | Only requests from the listed IPs or ranges, one per line, are accepted | 403 |
| Group | One group, or several in priority order; decides the line and the price | 503 when none of its groups offers the model |
| Allow balance checks | Under Advanced: lets monitoring scripts read the account balance with just this key | — |
Keep in mind:
- The cap is cumulative and does not reset each month. For a monthly budget, set the cap at the start of each month to the amount used so far plus the month's budget.
- All keys share the account balance. When it runs out, every key gets 403 with the code
insufficient_user_quota; see Errors and retries. - For critical workloads, give a key several groups so it fails over when the main line has trouble; see LLM API high availability.
Usage per key
- Logs: every record has the time, model, group, API key, tokens and cost. Filter by API key name and choose Show stats; Spend in period is that key's usage charges for the selected time, while money returned for failed async tasks is recorded separately as Refund records.
- Dashboard: the Keys and groups card sums spend by key, group and model, which suits comparing projects. The dashboard sums by the hour and is for reference; Logs are the record of actual charges.
- Export: the Export button on Logs downloads a CSV for finance. The full month-end routine is in Cost allocation and reconciliation.
Personal access tokens for scripts
When a script needs to check the balance, pull usage on a schedule or manage API keys in bulk, create a personal access token under Account settings → Access tokens. Do not hand the account password to a script:
- Grant only the permissions the script needs, such as "View usage logs, statistics and security log" or "View balance and top-up history".
- Pick an expiry: 7, 30, 90 or 365 days, or never.
- You verify your identity to create it, and the token is shown only once, so store it in your secret manager right away.
- The script sends it in the request header
Authorization: Bearer <token>when it calls the console API.
Personal access tokens are not API keys: API keys call models, while access tokens call the console API within the permissions you granted. Delete tokens you no longer use.
Low-balance alerts
Under Account settings → Balance alerts, turn on the low-balance alert. When the balance drops from above the threshold to below it, you get one notice by email or webhook; a webhook can carry a signing secret so your service can verify it. Since the whole team shares one balance, send alerts to an on-call mailbox or a chat bot rather than one person's inbox.
Protecting the owner's account
The console can create, reveal and delete every key, so protect the owner's account on its own:
- Only the owner signs in to the console; do not share the password.
- Under Account settings → Security, turn on two-step verification: sign-in and sensitive actions then also ask for a code from an authenticator app. Keep the backup codes somewhere safe.
- Sessions on the same page lists the browsers signed in to the account; sign out any device you do not recognize and change the password.
- The Security log records sign-ins, security changes, and creating, editing, enabling or disabling, deleting and revealing API keys, with the time, result, IP and device. Check it regularly.
When people or projects change
| Situation | What to do |
|---|---|
| A member leaves | Disable their development key; replace any production key they had access to with a new one, then disable the old one |
| A contract or pilot ends | The key expires on its own; disable it by hand if it ends early |
| A project shuts down | Disable all of its keys and decide about deleting them after the month is closed |
| A key may have leaked | Disable it now, replace it, then check Logs for unexpected calls; see API key security best practices |
Disabling beats deleting: a disabled key can be turned back on, while a deleted key only shows as a deleted key with its id under Keys and groups on the Dashboard, which makes per-key reviews harder.
For bulk purchasing and invoices, see Enterprise; for account security features and what the platform records, see Security & compliance.
FAQ
Can team members get their own sub-accounts?
No. An account has no member sub-accounts, so a team splits permissions and spend with API keys. Each member, project and environment gets its own key, and only the account owner signs in to the console; never share the account password.
Does a key's spending cap reset every month?
No, the cap is cumulative. To run a monthly budget, at the start of each month set the key's cap to the amount already used plus this month's budget.
Does each key have its own balance?
No. All keys draw on the account balance, and a cap only limits how much a single key can spend. When the account balance runs out, every key fails.
How does finance get the usage data?
Filter Logs in the console by time and API key name, then export a CSV. For a scheduled pull, create a personal access token with read-only permissions for the script.
What do we do when someone leaves or a contract ends?
Disable the keys they used. If they had access to a production key, create a new one, switch production to it, then disable the old one. Disabling beats deleting, since a disabled key can be turned back on and still shows by name on the Dashboard.