ベース URL
バージョニング
すべてのリソースエンドポイントには/v1 プレフィックスが付きます。OAuth およびディスカバリーエンドポイントにはバージョンが付きません。
認証
ほとんどのエンドポイントには Bearer トークンが必要です。Authorization ヘッダーに指定してください：
レスポンス形式
すべてのレスポンスは JSON を返します。成功したレスポンスには標準の HTTP ステータスコードが使用されます：エラーレスポンス
バリデーションエラーは422 ステータスを返し、どのフィールドが失敗したかの詳細が含まれます：
run がどの計算機を使ったか
run の計算機は 2 つのフィールドで表され、それぞれ別の問いに答えます。
マネージドでは両者が一致します（要求したティアがそのまま実機なので、
compute_type はそのティア、例 gpu-h100）。BYO では一致しません。
compute_type はクラスタ自身が名乗った GPU 機種（sinfo の GRES type、
例 nvidia_gb200）で、報告が無ければ unknown です。したがって値は固定の
集合ではなく自由文字列になります。
run 開始時に送る compute_type は意味が違います。あちらは「何を要求するか」
で、BYO では GPU 要求の導出に使う互換ティアを載せます。要求と記録は別の値で、
BYO では一致しません。
ダウンロード URL
ファイルの内容を返すエンドポイント（run のログstdout_url / stderr_url、
成果物の download_url）は、バイト列そのものではなく短命な presigned URL を
返します。有効なのは発行から最長 1 時間で、ログの URL はキャッシュ経由で
返るため、残り時間はこれより短いことがあります。
これらの URL は保存しないでください。保存した URL は後で
Request has expired しか返しません。代わりに run_id（と成果物のパス）を
保存し、実際にファイルが必要になった時点で取り直してください。
エンドポイントグループ
サイドバーを使用して、グループ別に整理されたすべての利用可能なエンドポイントを参照できます：- リポジトリ — リポジトリの登録、一覧表示、管理
- リポジトリファイル — リポジトリ内のファイルを参照
- コード分析 — コード分析の開始、監視、管理
- コード実行 — コードの実行と実行結果の取得
- ラン ストリーミング — SSE を介したリアルタイムの stdout/stderr ログのストリーミング
- API キー — API キーの作成と取り消し
- 環境変数 — 実行用の環境変数の管理
- GitHub インテグレーション — GitHub リポジトリの接続と管理
- GitHub App Webhooks — push および pull request イベントを受信して自動分析を実行
- OAuth 2.0 — 認可、トークン、クライアント登録