Skip to main content
Sorsaは、すべてのユーザーに高速で安定したサービスを提供するため、共通のレート制限を設けています。エンドポイント別の区分やローリングウィンドウはなく、1つの上限に合わせて設計できます。

基本ルール:毎秒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-remainingx-ratelimit-resetヘッダーはありません。毎秒リセットされるため、ヘッダーで残りの件数を追跡しても実用上の利点が少なく、処理が複雑になるためです。

上限内に収める方法

通常の処理で毎秒20リクエストに近づくことはあまりありません。バッチ処理や大規模データセットを扱う場合は、次の2つの方法が使えます。

方法1:リクエスト間に一定の待機時間を入れる

単一のワーカーで順番に処理する場合、各レスポンスの後に50ms以上待機することで送信速度を制限できます。余裕を持たせるには、待機時間を長くしてください。同じキーを複数のワーカーで共有する場合は、共通のレートリミッターを1つ使います。各ワーカーが個別に50ms待つだけでは、合計を毎秒20リクエスト以内に抑えられません。 Python
JavaScript

方法2:429を受け取ったら再試行する

最大速度で実行し、制限に達したときに対応したい場合は、429を検出して短時間待機してから再試行します。 Python
JavaScript
実際には両方を組み合わせると効果的です。短い待機時間で429を予防し、再試行処理で取りこぼしに備えます。

バッチエンドポイントで必要な送信量を減らす

速度を最適化する前に、バッチエンドポイントで総リクエスト数を減らせないか確認してください。
  • /info-batchは1リクエストで最大100件のユーザープロフィールを取得します
  • /tweet-info-bulkは1リクエストで最大100件のツイートを取得します
バッチリクエストも通常のリクエストと同じく、レート制限と割り当て量の両方で1件として数えます。多数のユーザーやツイートを取得する場合、個別のリクエストを並列で送るより、ほとんどの場合バッチ処理のほうが効率的です。詳しくはAPI利用の最適化を参照してください。

より高い上限が必要な場合

リアルタイム監視のパイプラインで毎秒100リクエスト以上など、毎秒20リクエストを超える継続的な処理が必要な場合は、営業へのお問い合わせまたはDiscordで、専用インフラとカスタムプランをご相談ください。

次のステップ