Skip to main content

API Overview

The Token Management API lets you handle the full lifecycle of your API keys in code, instead of clicking through the console one key at a time. The most common use case is batch issuance: giving each team member, downstream customer, or project its own key, each with its own limits on how much it can spend, which models it can call, and how long it stays valid.

Quota limit

remain_quota caps how much this key can spend in total

Model limit

models sets an allowlist; calls to anything outside it are rejected

Expiry limit

expired_time sets an expiry timestamp, after which the key stops working
If you only need one or two keys, the console is faster — see How to create an API key. This API is aimed at automated issuance, scheduled rotation, or integrating key management into your own systems.

How to Get Your System Token

The Token Management API authenticates with a System Token, which is not the same thing as an API key.
1

Access Console

Visit api.apiyi.com/account/profile to access your profile page
2

Find System Token

Locate the “Account Options - System Token” section at the bottom of the page
3

Generate AccessToken

Enter your account password to receive an AccessToken that can be used for subsequent API queries
Get System Token
A system token can create and delete API keys. Treat it like your account password.A system token cannot call models directly — using it against /v1/chat/completions is rejected — but it can create API keys that can. Leaking a system token is therefore considerably worse than leaking a single API key. Store it in a secret manager rather than in code, never commit it to a repository, and rotate it periodically.

Endpoints

All endpoints authenticate the same way: put the raw system token in the Authorization header, with no Bearer prefix. The base URL is https://api.apiyi.com.

Creating a Token

Request Example

Request Fields

unlimited_quota defaults to false and remain_quota defaults to 0 — omitting both produces a token with zero quota that cannot be used. Either set remain_quota explicitly or set unlimited_quota to true.
Use the models field for the model allowlist.The response structure also contains model_limits, model_limits_enabled, and allow_ips. Passing these does not raise an error — the endpoint still returns 200 — but they currently have no effect, and reading the token back shows them unset. Use models to restrict available models. Source-IP restrictions need to be implemented on your own side for now.

Response Example

The key in the response is plain text and does not include the sk- prefix. You need to prepend it yourself — in the example above the actual API key is sk-K1RPzapu….Save and distribute the key at creation time, and do not leave response bodies containing key sitting in log files.

Batch Creation

There is no server-side batch endpoint — passing something like count in the request body has no effect and still creates a single token. Batch issuance is done by looping on the client.

Using the Three Limits

Quota limit

remain_quota caps what the token can spend. The conversion matches the Balance Query API:

Conversion Rule

500,000 quota = $1.00 USD
For example, to issue a downstream customer a key capped at $10, set remain_quota to 5000000 with unlimited_quota set to false. Consumption so far is readable from the token’s used_quota field.

Model limit

models is a comma-separated allowlist. Once set, calling a model outside the list is rejected:
The response is HTTP 403 and no charge is incurred. Omitting models means no restriction.

Expiry limit

expired_time is a Unix-seconds timestamp, with -1 meaning never. For example, a key that expires in 30 days:

Listing Tokens

Key fields:

Updating a Token

The update endpoint requires the complete object — it is not a patch.The correct flow is: GET the full token object, modify the fields you want to change, then PUT the whole object back. Sending only the changed fields will clear the rest.

Disabling and Deleting

Disable (keeps the record)

Once disabled, the key stops working immediately — calls with it return 401 — but the token record and its usage history are retained.

Delete (irreversible)

Batch deletion is likewise a client-side loop:
Deletion cannot be undone. If you only want to suspend a key temporarily, disable it instead — the usage history stays available for reconciliation.

FAQ

The key in the response does not include the sk- prefix. Prepend it yourself: the usable API key is sk- followed by the returned value.
Most likely neither remain_quota was set nor unlimited_quota was set to true at creation. That default combination produces a token with zero quota. Recreate it with one of the two specified explicitly.
Those fields — along with model_limits_enabled — currently do not take effect. Passing them raises no error but nothing is stored. Use models to restrict available models; source-IP restrictions need to be handled on your own side for now.
There is no server-side batch endpoint, and passing something like count in the body has no effect. Loop the create call on the client instead — see the batch creation section above.
The update endpoint requires the complete object. GET the full object first, modify it, then PUT the whole thing back rather than sending only the changed fields.
Disabling (status: 2) stops the key working immediately but keeps the record and usage history, and you can set it back to 1 at any time. Deleting is irreversible and removes the record. For temporary suspension, prefer disabling.
The token’s used_quota field is that key’s cumulative spend (÷ 500,000 = USD). For a per-period breakdown or call-level detail, use the Log Query API with the token_name filter.

Important Notes

A system token is not an API key, and the two are not interchangeable
  • An API key (starting with sk-) is for /v1/* inference endpoints
  • A system token (a plain string with no prefix) is for /api/* management endpoints
Mixing them up returns 401 and an invalid-token error respectively.
Handle plaintext keys carefullyBoth the create response and the token list return keys in plain text. Therefore:
  • Do not write response bodies containing key into log files or commit them to a repository
  • Distribute keys to team members over secure channels, not group chats
  • This plaintext does not carry the sk- prefix, so common secret scanners may not detect it — do not rely on automated checks to catch it for you
Operational tips
  • When creating in bulk, add a modest delay between calls to avoid high instantaneous concurrency
  • Give each key a meaningful name (such as team-alice or prod-webhook) so you can attribute usage by token_name in the logs later
  • For rotation: create the new key, shift traffic, disable the old key, observe for a while, and only delete it once you confirm no calls remain

Related Documentation