レート制限（Indeed PLUS）
Indeed PLUS API のレート制限を管理します。
概要
#API 呼び出しが多すぎると、Indeed のサービスを妨げる可能性があります。Indeed のシステム、顧客、パートナーを保護するため、Indeed は API クライアントにレート制限を適用します。
Indeed PLUS APIを呼び出すと、5,000ミリ秒後にタイムアウトとなります。
Indeed は、クライアントが実行する各 GraphQL 操作のコストを測定します。各クライアントには予算があります。60 秒以内の操作のコストが予算を超えると、Indeed はそのクライアントの以降の呼び出しをブロックし、HTTP ステータスコード 429 を返します。
Indeed は、クライアントごとに個別のローリング合計を保持します。操作の 60 秒後に、Indeed はそのコス トを合計から削除し、新しい呼び出しに使える容量が空きます。
この例は、予算が 100 の Indeed PLUS API に対するレート制限を示しています。単位は説明のためのものです。
| 時刻 | パートナーの操作 | コスト | Indeed からのレスポンス | ローリング合計 予算: 100 |
|---|---|---|---|---|
| 12:00:00 | 操作なし | 0 | レスポンスなし | 0 |
| 12:00:30 | Call A | 50 | 成功 | 50 |
| 12:01:00 | Call B | 50 | 成功 | 100 （予算に到達） |
| 12:01:15 | Call C | 10 | エラー（HTTP 429） | 100 （予算に到達） |
| 12:01:30 | 操作なし | Call A のコストが失効する | 50 |
手順
#1. レート制限を確認する
#Indeed は、各クライアントのニーズに応じてティアを割り 当てます。ティアごとにレート制限が異なります。クライアントのティアを確認するには、Indeed の担当者に連絡してください。
2. レート制限に備える
#連携では、レート制限に対応できるようにしてください。すべてのクライアントに適した単一の方法はないため、顧客のニーズに合う方法を選んでください。
3. レート制限から復旧する
#クライアントにレート制限が適用されると、Indeed はその API 呼び出しを処理しません。ローリング合計から十分なコストが失効するまで、各呼び出しは HTTP 429 を返します。
これを解消するには、次を実施してください。
- リクエストパターンを確認する — プロセスが API 呼び出しを過剰に実行していないか確認します。
- ベストプラクティスに従う — レート制限を回避するをご覧ください。
- Indeed の担当者に連絡する — トラフィックの見積もりを送信し、ティア変更の支援を受けます。
4. トラフィックの増加に備える
#リクエスト量が安定しているか緩やかに増加しており、操作があまり変わらず、このページのベストプラクティスに従っていれば、クライアントにレート制限が適用される可能性は低くなります。トラフィックが徐々に上限に近づいた場合は、Indeed から連絡する場合があります。
急な増加はリスクが高くなります。ローンチやキャンペーンが原因の場合もあれば、バグや悪意のある主体が原因の場合もあります。Indeed はこれらを常に区別できるとは限らないため、クライアントにレート制限を適用する場合があります。
リクエスト量が 25% 以上増加すると見込まれる場合や、操作が大きく変わる場合は、2 週間前までに Indeed の担当者に連絡してください。影響の見積もりに役立つデータを共有してください。
- リクエストの増加 — ピーク時の追加リクエスト数、関係する操作、増加の期間。
- 操作の変更 — 変更される操作と、その例。
5. レート制限を回避する
#レート制限の可能性を下げるには、次のベストプラクティスに従ってください。
ログを記録して監視する
#レート制限を検知できるように、すべてのリクエストの結果をログに記録し、レスポンスのステータスコード、特に 2xx 以外のコ ードを監視してください。
ボットを検知してブロックする
#ボットによるトラフィックが疑われる場合のアラートを設定します。必要に応じてボットからのリクエストをブロックし、理想的には自動でブロックします。
ユーザー入力を検証する
#無効なリクエストがローリング合計に追加されないように、ユーザー入力を検証してください。
最小限のデータをクエリする
#必要なデータだけをリクエストしてください。これにより、各操作のコストが下がります。
クローラーのクロール頻度を下げる
#Googlebot などのクローラーを許可している場合は、トラフィックが多い時間帯にクロール頻度を制限することを検討してください。
再試行までに待機する
#システムで失敗したリクエストを再試行する場合は、レート制限が適用されたときに再試行の間隔を長くし、再試行の回数を減らしてください。
関連項目
#- レート制限 — 求人情報連携APIのレート制限を説明します。
- 429 Too Many Requests （新しいウィンドウで開きます） — レート制限された呼び出しが返すステータスコードを説明します。
- Google のクロール頻度を下げる （新しいウィンドウで開きます） — Googlebot のクロールを遅くする方法を説明します。