基本ルール:毎秒20リクエスト
各APIキーの上限は毎秒20リクエストです。レート制限はこれだけで、エンドポイント別の上限、15分単位のウィンドウ、1時間ごとのリセット、プラン間の違いはありません。 同じキーを使うすべてのワーカーの合計リクエスト頻度を管理してください。個々の処理で送信間隔を調整していても、429レスポンスへの対処は必要です。
次の点も確認してください。
- 上限はIPアドレス単位ではなく、APIキー単位です。複数のキーがある場合、それぞれ毎秒20リクエストまで使えます。
- すべてのリクエストを同じように数えます。
/infoの1回の呼び出しも、100ツイートを取得する/tweet-info-bulkの1回の呼び出しも、1リクエストです。 - スライディングウィンドウではありません。 カウントは毎秒リセットされます。
T+0.00で20リクエストを送信した場合、T+1.00でさらに20リクエストを送信できます。
上限を超えた場合
1秒間に20件を超えて送信すると、超過分には429 Too Many Requestsが返ります。データが失われたり、キーにペナルティが課されたりすることはありません。次の秒まで待って再試行してください。
x-ratelimit-remainingやx-ratelimit-resetヘッダーはありません。毎秒リセットされるため、ヘッダーで残りの件数を追跡しても実用上の利点が少なく、処理が複雑になるためです。
上限内に収める方法
通常の処理で毎秒20リクエストに近づくことはあまりありません。バッチ処理や大規模データセットを扱う場合は、次の2つの方法が使えます。方法1:リクエスト間に一定の待機時間を入れる
単一のワーカーで順番に処理する場合、各レスポンスの後に50ms以上待機することで送信速度を制限できます。余裕を持たせるには、待機時間を長くしてください。同じキーを複数のワーカーで共有する場合は、共通のレートリミッターを1つ使います。各ワーカーが個別に50ms待つだけでは、合計を毎秒20リクエスト以内に抑えられません。 Python方法2:429を受け取ったら再試行する
最大速度で実行し、制限に達したときに対応したい場合は、429を検出して短時間待機してから再試行します。
Python
429を予防し、再試行処理で取りこぼしに備えます。
バッチエンドポイントで必要な送信量を減らす
速度を最適化する前に、バッチエンドポイントで総リクエスト数を減らせないか確認してください。/info-batchは1リクエストで最大100件のユーザープロフィールを取得します/tweet-info-bulkは1リクエストで最大100件のツイートを取得します