Skip to main content
/v1 API では、互いに独立した 2 つのリクエスト上限が適用されます。いずれか一方の上限に達した場合、リクエストは拒否されます。 API キーごとの上限は、キーが使用される場所にかかわらず、そのキーに対して適用されます。IP ごとの上限は、未認証のトラフィックに対する唯一の上限であり、認証済みトラフィックに対しては 2 つ目の上限となります。
制限は認証の前に適用されるため、無効な認証情報または欠落した認証情報を含むリクエストも、送信元の上限に対してカウントされます。具体的な上限値は運用者によって設定されており、変更される場合があります。以下のレスポンス仕様は安定したインターフェースであるため、これに基づいて実装してください。
いずれかの Basic 認証情報の形式で認証します。詳細はクイックスタート(apikey:secret または secret:)を参照してください。 BASE には、組織のリージョンのホストを設定します。詳細はリージョンを参照してください。

429 レスポンス

上限に達した場合、API は 429 Too Many Requests を返します。レスポンスには、秒単位の Retry-After ヘッダーと、標準の problem-details 形式の本文が含まれます。
429 Too Many Requests
レスポンスには、どちらの上限に達したかは示されません。すべての 429 を同様に扱い、待機してから再試行してください。

429 の処理

1

Retry-After に従う

再試行する前に、少なくとも Retry-After ヘッダーに示された秒数だけ待機してください。それより早く再試行しても、拒否されるリクエストで上限を再び消費するだけです。
2

繰り返し発生する場合は指数バックオフを使用する

再試行が再度拒否された場合は、バックオフ時間を増やし、ランダムなジッターを加えて、並列ワーカーが同時に再試行しないようにします。ローカルの上限に合わせてサーバーの Retry-After を短縮することは決してしないでください。サーバーが、再試行の許容範囲を超える待機を求めている場合は、再試行を中止し、処理を後で実行するようスケジュールしてください。
3

リクエストレートを平準化する

バースト的な送信よりも、一定のリクエストレートを維持してください。一括読み取りの場合は、最大ページサイズ(limit=500)を使用すると、より少ないリクエスト数でコレクション全体を取得できます。詳細はページネーションを参照してください。複数の一覧取得を並列で実行する場合(たとえば Power BI のテーブルなど)は、同時実行数を控えめに保ち、Retry-After に従って、一時的な 429 によって更新全体が失敗しないようにしてください。
この例では、GET リクエストに対する 429 レスポンスのみを再試行します。試行は最大 5 回、試行間の待機は最大 60 秒です。その他のエラーでは直ちに停止します。ネットワークのタイムアウトは呼び出し元に伝播されます。タイムアウトと再試行の上限は、ワークロードに合わせて設定してください。requests は、読み取りタイムアウトを全体の期限ではなく、データ受信中の最大アイドル時間として解釈します。 LIVING_SECURITY_API_KEY はシークレットマネージャーから読み込んでください。この例を実行する前に、requests をインストールしてください。使用するには get_with_retry("/organization") を呼び出します。
Python
このループを書き込み操作にそのまま適用しないでください。書き込み後のタイムアウトは、接続が失敗する前にサーバーが書き込みをコミットした可能性があることを意味します。書き込みを再実行するのは、その操作のリファレンスで冪等性が明示的に記載されている場合に限り、同じキーとペイロードを維持して行ってください。それ以外の場合は、再試行する前にリソースの状態を照合してください。

推奨される更新スケジュール

更新頻度は、API キーの上限とページサイズに照らして決定してください。大規模なコレクションの全履歴の読み込みは一度限りのコストです。定常的な更新では増分ウィンドウを使用し、各実行が上限を大きく下回るようにしてください。limit=500 は必ず明示的に設定してください。デフォルトの 25 ではリクエスト数が大幅に増加します。