リクエスト実行状況を意識して、APIを利用する必要はありますか？¶

ReproのAPIは単位時間あたりのリクエスト数に上限（Rate Limit）があり、上限を超えると 429 Too Many Requests エラーが返ります。そのため、アクセス上限を考慮したリクエスト設計が重要です。

上限の仕様¶

機能ごとに単位時間あたりのアクセス上限は異なります。それぞれ以下のとおりです。

機能名	アクセス上限
オーディエンスAPI	APIトークンごとに10分あたり15件
プッシュAPI	APIトークンごとに1分あたり1000件
ユーザープロフィールAPI	APIトークンごとに1分あたり1000件
ユーザープロフィールバルクインポートAPI v3	APIトークンごとに10分あたり10件
削除ユーザー登録API	APIトークンごとに1分あたり1000件
ニュースフィードAPI	Clientトークンごとに1分あたり3000件

注釈

アクセス上限設定値は、機能単位でのAPIトークンごととなります。例えば、プッシュAPIとユーザープロフィールAPIは同じAPIトークンを利用していますが、別機能のため同時にリクエストしたとしても、それぞれ1件ずつのカウントとなります。

リクエスト数がアクセス上限を超えると、 HTTP Status 429 (Too Many Requests) が返ります。

上限に対する現在の使用状況¶

APIレスポンスに含まれる以下のHTTPヘッダーを使用して、現在の使用状況を監視できます。

ヘッダー名	説明
`X-RateLimit-Limit`	単位時間あたりのアクセス上限
`X-RateLimit-Remaining`	アクセスできる残り回数
`X-RateLimit-Reset`	アクセス数がリセットされる時刻(unixtime)
`Retry-After`	再実行可能になるまでの秒数

上限への対処法¶

APIレスポンスに含まれるHTTPヘッダーをもとに事前に制御することと、上限エラーに適切に対応することの両方があり、どちらも対応することをお勧めします。

上限に達する前の対処¶

X-RateLimit-Remaining と X-RateLimit-Reset をもとに、リクエスト数が上限を超えないよう制御してください。

Remaining が少なくなってきた場合は、リクエスト間隔をあける
Reset 時刻まで待機することで、上限超過を防ぐ
短時間にリクエストを集中させない
可能な場合はリクエストをまとめる

上限に達した場合の対処¶

アクセス上限を超え、 429 Too Many Requests が返った場合は Retry-After をもとに、リトライ処理を行ってください。

Retry-After の値を参考に一定時間待機する
再度 429 Too Many Requests が発生した場合は、さらに待機してリトライする
短時間での連続リトライは避ける

警告

429 Too Many Requests が返った場合は、 Retry-After の秒数より、1秒以上は待機時間を延ばしてください。 Retry-After の秒数を待ってリクエストを行った場合でも、再実行可能になるまでコンマ秒足りずに再度 429 Too Many Requests が返ることがあります。