Skip to main content

API 概要

Token 管理 API では、コンソールでキーを 1 つずつクリックして操作する代わりに、APIキーのライフサイクル全体をコードで管理できます。 最も一般的なユースケースは 一括発行 です。各チームメンバー、下流の顧客、またはプロジェクトにそれぞれ専用のキーを割り当て、利用できる金額の上限呼び出せるモデル有効な期間 にそれぞれ制限を設定します。

クォータ上限

remain_quota は、このキーが合計で利用できる金額の上限を設定します

モデル上限

models は許可リストを設定し、それ以外への呼び出しは拒否されます

有効期限上限

expired_time は有効期限のタイムスタンプを設定し、その後はキーが動作しなくなります
1つか2つのキーだけ必要なら、コンソールのほうが速いです。APIキーの作成方法を参照してください。この API は、自動発行、定期ローテーション、またはキー管理を自社システムに組み込む用途に向いています。

システムトークンの取得方法

トークン管理 API は システムトークン で認証します。これは API キーとは別物です。
1

コンソールにアクセス

プロフィールページにアクセスするには api.apiyi.com/account/profile を開いてください
2

システムトークンを見つける

ページ下部の「アカウントオプション - システムトークン」セクションを見つけてください
3

アクセストークンを生成

アカウントのパスワードを入力すると、その後の API クエリに使用できるアクセストークンを取得できます
システムトークンを取得
システムトークンでは API キーの作成と削除ができます。アカウントのパスワードと同じように扱ってください。システムトークンはモデルを直接呼び出すことはできません — /v1/chat/completions に対して使用すると拒否されます — しかし、使用できる API キーを作成できます。そのため、システムトークンの漏洩は 1 つの API キーの漏洩よりもはるかに深刻です。 コード内ではなくシークレットマネージャーに保管し、リポジトリには決してコミットせず、定期的にローテーションしてください。

エンドポイント

すべてのエンドポイントは同じ方法で認証します。生のシステム token を Authorization ヘッダーに入れ、Bearer プレフィックスは付けません ベース URL は https://api.apiyi.com です。

トークンの作成

リクエスト例

リクエスト項目

unlimited_quota のデフォルトは false で、remain_quota のデフォルトは 0 です — 両方を省略すると 使用できないクォータ 0 のトークンが作成されます。remain_quota を明示的に設定するか、 unlimited_quotatrue に設定してください。
モデルの許可リストには models フィールドを使用してください。レスポンス構造には model_limitsmodel_limits_enabledallow_ips も含まれます。 これらを渡してもエラーにはならず、エンドポイントは引き続き 200 を返しますが、現時点では 効果はなく、トークンを取得し直しても未設定のままです。利用可能な モデルを制限するには models を使用してください。送信元 IP の制限は、現時点ではご自身で 実装する必要があります。

レスポンス例

レスポンス内の key はプレーンテキストで、sk- プレフィックスは含まれていません。 自分で 先頭に付ける必要があります — 上の例では、実際の API キーは sk-K1RPzapu… です。作成時にキーを保存して共有し、key を含むレスポンス本文を ログファイルに残したままにしないでください。

バッチ作成

サーバー側のバッチエンドポイントはありません — リクエストボディに count のようなものを渡しても 効果はなく、単一の token が作成されるだけです。バッチ発行はクライアント側でループさせて行います。
1人のユーザーが保持できる token は最大 1,000 個です。 これはアカウント全体の上限であり、無効化されているが削除されていない token もカウントされます。上限に達すると作成エンドポイントは失敗します — 使っていない token を削除して枠を空けてください。バッチ実行の前に、GET /api/token/?p=0&page_size=100 をページングして既にあるものを数えてください。キーをローテーションする場合は、実際に「新しいキーを作成 → トラフィックを移行 → 古いキーを無効化 → 呼び出しがなくなったら削除」という最後の手順まで完了させてください。削除せずに無効化するだけだと枠が占有されたままになるため、数回のローテーションで上限に達してしまいます。

3つのリミットの使い方

クォータ制限

remain_quota は token が使える金額の上限を設定します。換算は 残高照会 API と一致します:

換算ルール

500,000 クォータ = $1.00 USD
たとえば、下流の顧客に $10 を上限とするキーを発行するには、remain_quota5000000 に、unlimited_quotafalse に設定します。これまでの消費量は、token の used_quota フィールドから読み取れます。

モデル制限

models は、カンマ区切りの許可リストです。一度設定すると、リスト外の model を呼び出すと拒否されます:
レスポンスは HTTP 403 で、課金は発生しませんmodels を省略すると、制限なしを意味します。

有効期限制限

expired_time は Unix 秒のタイムスタンプで、-1 は期限なしを意味します。たとえば、30日後に期限切れになるキー:

トークン一覧

主要フィールド:

token の更新

更新エンドポイントには完全なオブジェクトが必要です。パッチではありません。正しい流れは次のとおりです: GET 完全な token オブジェクトを取得し、変更したいフィールドを修正してから、 PUT オブジェクト全体 を送り返します。変更したフィールドだけを送ると、残りはクリアされます。

無効化と削除

無効化(記録は保持されます)

無効化すると、キーは直ちに動作しなくなります — そのキーを使った呼び出しは 401 を返します — ただし token の記録とその利用履歴は保持されます。

削除(元に戻せません)

一括削除も同様にクライアント側のループです:
削除は元に戻せません。key を一時的に停止したいだけなら、代わりに無効化してください — 利用履歴は照合用に引き続き利用できます。

よくある質問

レスポンス内の key には sk- の接頭辞が含まれていません。自分で先頭に付けてください。 使える API key は、返された値の前に sk- を付けたものです。
おそらく、作成時に remain_quota が設定されておらず、または unlimited_quotatrue に設定されていませんでした。 そのデフォルトの組み合わせだと、クォータが 0 の token になります。どちらか一方を明示的に指定して再作成してください。
それらのフィールドは、model_limits_enabled とあわせて、現時点では有効になりません。渡しても エラーにはなりませんが、何も保存されません。利用可能なモデルを制限するには models を使ってください。送信元 IP の制限は、当面は各自で対応する必要があります。
サーバー側のバッチ用エンドポイントはなく、body に count のようなものを渡しても 効果はありません。代わりにクライアント側で create 呼び出しをループしてください。上の一括作成セクションを参照してください。
1 ユーザーあたり最大 1,000 個です。無効化されていても削除されていない token は、その合計に含まれます。 上限に達すると、不要な token を削除するまで作成は失敗します。key をローテーションする際は、 最後に削除ステップまで完了させてください。無効化だけではスロットが占有されたままです。
update エンドポイントは完全なオブジェクトを必要とします。まず GET で完全なオブジェクトを取得し、編集してから、 変更したフィールドだけを送るのではなく PUT 全体を送り返してください。
無効化(status: 2)すると key はすぐに動作しなくなりますが、レコードと使用履歴は保持され、 いつでも 1 に戻せます。削除は元に戻せず、レコードも削除されます。一時的に停止するなら、無効化を使うのがおすすめです。
token の used_quota フィールドが、その key の累計使用額です(÷ 500,000 = USD)。期間ごとの内訳や呼び出し単位の詳細は、 コンソールのログページで token 名で絞り込んで確認できます — 呼び出し記録を確認する方法 を参照してください。

重要な注意事項

システム token は API key ではなく、両者は互換性がありません
  • API keysk- で始まるもの)は /v1/* 推論エンドポイント向けです
  • システム token(プレフィックスのないプレーンな文字列)は /api/* 管理エンドポイント向けです
取り違えると、それぞれ 401 と invalid-token エラーが返ります。
プレーンテキストのキーは慎重に扱ってください作成レスポンスと token リストの両方で、キーはプレーンテキストで返されます。そのため:
  • key を含むレスポンス本文をログファイルに書き込んだり、リポジトリにコミットしたりしないでください
  • キーはグループチャットではなく、安全なチャネルでチームメンバーに共有してください
  • このプレーンテキストには sk- プレフィックスが付かないため、一般的な secret scanner では検出できない場合があります — 自動チェックに頼って見つけさせようとしないでください
運用のヒント
  • 一括作成するときは、高い瞬間的な同時実行数を避けるため、各呼び出しの間に少し遅延を入れてください
  • 各キーに意味のある name(たとえば team-aliceprod-webhook)を付けて、後でログ上で token_name ごとの使用状況を把握できるようにしてください
  • ローテーションでは、新しいキーを作成し、トラフィックを切り替え、古いキーを無効化して、しばらく様子を見てください。 呼び出しが残っていないと確認できてから削除してください

関連ドキュメント