認証方式

すべてのリクエストは、AuthorizationヘッダーでAPIキーを渡します。

Authorization: Bearer lp_live_XXXXXXXX…    （ワークスペースキー）
Authorization: Bearer lpp_live_XXXXXXXX…   （パートナーキー）

キーはダッシュボードで作成し、作成時に一度だけ表示され、SHA-256のハッシュとして保存 されます。サポートを含め、誰も紛失したキーを復元できません。キーをなくした場合は、そのキー を失効させて新しいものを作ることになります。

キーの種類

• ワークスペースキー（lp_live_…）は1つのワークスペースの中で動きます。リンク、分析、 ドメイン、監査証跡、ワークスペースのWebhookが対象です。ワークスペースの管理者が 設定 → APIキーで作成します。
• パートナーキー（lpp_live_…）はパートナーアカウントに対して動きます。クライアント、 プラン、ドメイン、決済、入金、パートナーのWebhookが対象です。パートナーの管理者が作成します。

ワークスペースキーで/partner/*を呼び出すと（その逆も同じく）403 forbiddenが返ります。 エンドポイントの系統は厳密に分けられています。

スコープ

スコープは作成時にキーごとに付与されます。リクエストには、そのエンドポイントが求めるすべて のスコープが必要です。足りない場合は、不足しているスコープ名を添えて 403 insufficient_scopeが返ります。

| スコープ | 許可される操作 | |---|---| | links:read / links:write | リンクの読み取り / 作成、更新、アーカイブ、削除 | | analytics:read | サマリー、時系列、内訳、上位リンク、CSVエクスポート、およびパートナー全体のクリック概要 | | domains:read / domains:write | ドメインの読み取り / 接続と切断 | | qr:read | リンクのQRコードの描画 | | workspace:read | ワークスペースのプロフィール、上限、監査証跡 | | webhooks:read / webhooks:write | Webhookエンドポイントの読み取り / 管理 | | partner:read | パートナーのプロフィール、プラン、利用量 | | clients:read / clients:write | クライアントの読み取り / 作成、変更、停止 | | plans:read / plans:write | パートナープランの読み取り / 管理 | | payments:read | 決済のミラーと入金 |

これがすべての一覧です。スコープは15個で、キーはこの中の名前しか持てません。QRコードはAPI では読み取り専用です。描画にはqr:readが必要で、QRの更新用エンドポイントが存在しないため、 QRの書き込みスコープもありません。

1つだけ間違えやすい組み合わせがあります。GET /partner/analytics/overviewには、パートナー キーでpartner:readではなくanalytics:readが必要です。分析のエンドポイントは、キーの種類 にかかわらず同じスコープを使います。

各連携には、必要最小限のスコープを持つ専用のキーを渡してください。ダッシュボードのウィジェット 用のキーならlinks:readとanalytics:readで十分ですし、プロビジョニングのスクリプトには clients:writeが必要です。

プランによる制限

APIアクセスはプランの機能（api_access）です。

• ワークスペースキーの場合、ワークスペースのプランとパートナーのプラットフォームプラン の両方にAPIアクセスが含まれている必要があります。
• パートナーキーの場合、パートナーのプラットフォームプランに含まれている必要があります。

APIアクセスのないプランには403 plan_restrictedが返ります。プランのないトライアルの ワークスペースは制限されません。

ローテーションと失効

キーの失効は即座に反映されます。次のリクエストには401 unauthorizedが返ります。停止時間 なしでローテーションするには、先に新しいキーを作り、連携を切り替えてから、古いキーを失効 させてください。各キーはlast_used_atを記録するので、失効させる前に、使われていない古い キーを簡単に見つけられます。

必要に応じて、キーに有効期限を設定することもできます。期限切れのキーは、失効させたキーと まったく同じ振る舞いになります。

望ましい運用

• キーは秘密情報です。シークレットマネージャーに保管し、クライアント側のコード、リポジトリ、 ログには決して置かないでください。
• 連携ごとに1つのキーにしてください。1つを失効させても他は壊れませんし、 監査証跡がすべての変更を、それを行ったキーに紐づけて記録します。