認証
リクエストは、すべての呼び出しでベアラートークンとして送信されるシークレット API キーによって認証されます。
Authorization ヘッダー
API キーをベアラートークンとして含めてください。サンドボックスキーは chsk_test_ プレフィックスを、本番キーは chsk_live_ を使用します。
curl "https://api.crisphive.com/v1/customers" \ -H "Authorization: Bearer chsk_test_4eC8xQ9mZ2pL7Ka0rT"
キーの管理
キーは設定 → 開発者から作成します — キーに名前を付け、作成時に一度だけ表示される値をコピーし、必要に応じて特定の権限スコープに制限し、いつでも無効化できます。
キーが作成者以上の権限を持つことはありません: 新しいキーのスコープは、たとえスコープリストを空のままにしても、作成するユーザーの権限が上限になります。作成時にそれを超えるスコープをリクエストすると、403 API_KEY_SCOPE_NOT_GRANTED で失敗します — フルサーフェスが必要な場合は、フルアクセスを持つユーザー（またはオーナー）にキーを作成してもらってください。
有効期限
API キーには有効期限があります。キーの有効期間は作成時に選択し（デフォルトは 30 日、1 日から 365 日まで）、そのキーの生存期間中は固定されます。有効期間を後から延長することはできない（キーの名前を変更しても変わりません）ため、キーの expires_at が変わることはありません。この値はキー API から返され、ダッシュボードにも表示されます — 読み取って切り替えのスケジュールを立ててください。
Crisphive は、キーの有効期限の 7 日前と、期限切れになった時点で、ビジネスのオーナーと管理者にメールを送信します。メールだけに頼らないでください — メールはビジネス宛てであり、必ずしもあなたに届くとは限りません。引き続き expires_at を読み取り、切り替えのスケジュールは自分で立ててください。
キーの更新
更新するには新しいキーを作成します — ローテーション用のエンドポイントはありません。ビジネスは環境ごとに最大 50 個のアクティブなキーを保持できるため、切り替えに特別な仕組みは不要で、ダウンタイムもありません:
ダッシュボードで代わりのキーを作成します。
新しいキーを連携にデプロイします。
新しいキーでトラフィックが流れていることを確認します（last_used_at、または Developers → Logs）。
ダッシュボードから古いキーを無効化します。
これは AWS がアクセスキーについて文書化しているのと同じ 2 キー方式の手順です。キーは設定から読み込み、ハードコードしないでください。そうすればステップ 2 はリリースではなく設定変更で済みます。キーが漏洩した場合は逆の順序で行ってください — 先に無効化してから代わりのキーを作成します。数回の呼び出しが失敗する方が、漏洩したキーを生かしておくよりましです。キー管理はダッシュボード専用です — キーの作成や失効のための公開 API はありません。
401 と error_code: "API_KEY_EXPIRED" を返します — API_KEY_INVALID（無効化・削除済み、または誤った値）とは意図的に区別されているため、アラートで更新漏れと無効化を見分けられます。他のビジネスの代理でアクセスする
API キーが認証するのは自分自身のビジネスです。他の Crisphive ビジネスが接続するプロダクトを作るなら、代わりに OAuth 2.1 を使ってください。各ビジネスオーナーが同意画面であなたのアプリを承認するため、キーが共有されることは一切ありません。