管理 API - GPT-Load

管理画面自体がこれらのエンドポイントを使います。Groupやキーの管理を自動化する場合は、これらを直接利用できます。

認証§

/api配下の保護されたエンドポイントでは Bearer 認証を使用します：

リクエストヘッダー

Authorization: Bearer AUTH_KEY または AccessKey

AUTH_KEY——管理権限です。設定を読み書きでき、Reveal などの機密操作も実行できます
AccessKey——自身の範囲内にあるホーム、モデル、使用量、マスキング済みリクエストログのみを参照できます。設定の変更やアップストリーム認証情報の表示はできません

書き込みまたはルート確認を行う場合はAUTH_KEYを使用してください。

レスポンス規約§

レスポンスは統一形式で、成功と失敗をcodeで区別します：

成功

{
  "code": 0,
  "message": "success",
  "data": { ... }
}

失敗

{
  "code": "エラー識別子",
  "message": "人間が読める説明"
}

成功時、codeは数値の0です。失敗時は文字列識別子です。型を確認してください。

主要資源§

パス	用途
/api/groups	Groupの追加・削除・更新・検索
/api/groups/{id}/credentials	認証情報管理、バッチインポート、実際の値の表示、ダウンロードを含む
/api/access-keys	AccessKey、上限と実値の確認を含む
/api/models	モデル情報
/api/model-prices	モデル価格、同期およびリセットを含む
/api/logs	リクエストログの検索
/api/usage	使用量およびコスト統計
/api/health	健康状態
/api/settings	実行時設定
/api/route/inspect	ルーティングチェック

管理画面で実際に送信されたリクエストを基準にしてください

エンドポイントのパラメーターを個別に列挙しないのは、APIが進化中で固定文書が古くなりやすいためです。最も確実な方法はブラウザの開発者ツールを開くことです。管理画面で操作を1度行い、送信されたリクエストを確認すれば、現行バージョンの正確なパラメーターを得られます。

いくつかの例§

すべてのGroupを列挙

curl http://127.0.0.1:3001/api/groups \
  -H "Authorization: Bearer $AUTH_KEY"

ヘルス状態を確認

curl http://127.0.0.1:3001/api/health \
  -H "Authorization: Bearer $AUTH_KEY"

ルーティングチェック：このリクエストはどこに行くか

curl -X POST http://127.0.0.1:3001/api/route/inspect \
  -H "Authorization: Bearer $AUTH_KEY" \
  -H "Content-Type: application/json" \
  -d '{"protocol":"openai-completions","external_model":"gpt-4o","access_key_id":1}'

access_key_idは管理画面に表示される AccessKey の数値 ID です。ルート確認は現在の設定に基づく候補だけを計算し、アップストリームへ実際のリクエストを送信しません。

注意事項§

公開ネットワークにさらさないでください

管理 API ではすべてのチャネル認証情報の実値を読み取れます（/revealのようなエンドポイントが該当します）。AUTH_KEYが漏洩するとすべてのアップストリームキーが漏洩します。
アクセス元を制限してください。設定方法はセキュリティと本番運用を参照してください。

スクリプトに AUTH_KEY をハードコードしない — 環境変数またはシークレット管理ツールを使います。
インターフェースはバージョンに応じて調整される — 自動化スクリプトを更新したら再検証します。
バッチ操作では冪等性に注意 — 同じ認証情報を繰り返しインポートしても重複分は自動でスキップされますが、書き込み前に確認してください。