Authentication

Xenodia public API は Bearer token を使います。Runtime call は server から送信し、長期 API key をブラウザに露出しないでください。

Header

Authorization: Bearer YOUR_LONG_TERM_KEY

cURL template

curl "https://api.xenodia.xyz/v1/models"

/v1/models は public endpoint なので API key は不要です。Chat、image、video、task retrieval は認証が必要です。

curl -X POST "https://api.xenodia.xyz/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $XENODIA_API_KEY" \
  -d '{"model":"gpt-6-astra","messages":[{"role":"user","content":"Hello"}]}'

Key handling

• 長期 key は server env、secret manager、または制御された agent runtime にだけ置く。
• ブラウザはあなたの backend を呼び出し、Xenodia key を直接持たない。
• agent や workflow ごとに key を分けると、revoke と audit が簡単になります。
• key rotation 時は agent runtime の skill/env 設定も更新します。

よくある status code

本番の指針

API key、owner wallet、agent wallet、model access permission は同じ security boundary の一部として扱います。ログには request ID と status code を残し、raw prompt、API key、private key は記録しません。

API key の一覧と失効

GET /v1/me/api-keys の keys 配列には、このアカウントの全 key のメタデータが含まれます。失効済み key も表示されます。既存の data フィールドは最新の有効な key のメタデータ、または null のままです。既存 key の秘密値は返しません。

作成時に秘密値を一度だけ返します。古い key は有効なままです。通常のローテーションは、新 key の作成、連携設定の更新、旧 key の明示的な失効の順に行います。漏えい時は直ちに失効してください。成功応答は { "ok": true } で、その後の認証リクエストから無効になります。他の key やブラウザセッションには影響しません。

セッション、更新、サインアウト

Access token と refresh token は、失効可能な同一ログインセッションに属します。POST /v1/auth/refresh の JSON body に refresh token を送信します。

{ "refresh_token": "YOUR_REFRESH_TOKEN" }

Refresh token は一度だけ交換できます。更新を直列化し、返された access token と refresh token を一緒に保存してください。使用済み token の再送は 401 です。通信がタイムアウトしても交換済みの場合があります。再試行が 401 なら、繰り返し再送せずにログインし直してください。

POST /v1/auth/logout は同じ JSON body を受け取り、更新後の token を含むセッション全体を失効させます。未期限切れの署名済み refresh token なら、交換済みでも同じセッションを終了できます。{ "ok": true } を確認するまで、サーバー側で終了したとは判断しないでください。ブラウザ保存領域の削除だけでは失効しません。

Access token で POST /v1/me/sessions/revoke-all を呼ぶと、このアカウントの全ログインセッションを終了します。呼び出し元も対象です。API key はどちらのサインアウト操作でも失効しません。

失効・期限切れは 401、停止されたアカウントは 403 です。セッション失効機能への移行後、セッション識別子 sid がない旧 access/refresh token は、一度ログインし直す必要があります。既存の API key は維持されます。クライアント側で token を解析せず、401 に応じて再認証してください。

同じログインセッションのタブは refresh とログアウトを連携します。複製したタブは短時間のメモリ内メッセージで更新済み token を受け取り、古い refresh token を再使用しません。長期的な認証情報は localStorage に保存しません。別のログインセッションには影響しません。セッション ID のない旧 token は再ログインが必要です。ページの復元時にもセッションを確認し、サーバー側で取り消された場合は access token の期限を待たずに再ログインを求めます。

招待コードは Google の新規登録のみに適用され、無効なコードが既存アカウントのログインを妨げることはありません。新規登録時に無効なコードがある場合は修正するか Continue without invitation を選択できます。再試行前に URL と保存済みのコードを消去します。