ストア上の顧客 1 人あたり毎分 3000 リクエストまで。全アプリで共有される上限で、既存のコストベース制限に追加して適用される。通常の購入者トラフィックなら対応不要、ただしリトライ処理は要確認。
顧客ごと・ストアごとのリクエスト数上限。
どのアプリが投げたかに関係なく、同じ顧客・同じストアなら同じ枠を消費。
通常の購入者トラフィックはこの上限を大きく下回る想定。
| 項目 | 変更前 | 変更後 |
|---|---|---|
| コストベースのレート制限 | あり | あり 継続 |
| 顧客単位のリクエスト上限 | なし | 新設 毎分 3000 回 / ストア |
| カウントの単位 | — | 顧客 × ストア（全アプリ合算） |
| 超過時の挙動 | — | HTTP 429 ＋ THROTTLED ＋ Retry-After |
| 開始日 / 移行期間 | 記載なし（記事は「now enforces」＝既に適用中という表現） | |
どのストアでも、Customer Account API を呼んでいるアプリはすべて対象。
通常の購入者のトラフィックは上限を十分に下回るため、多くの場合アクション不要。
Customer Account API を使うアプリは、リトライロジックが以下を満たしているか確認する。
レスポンスのステータスコードで 429 を判定。
レスポンスヘッダから待機時間を取得。
Retry-After の時間だけ待ち、同じリクエストを再送。
既存のコストベース制限は残ったまま、顧客単位のリクエスト数上限が上乗せ。どちらにも引っかかりうる前提で設計する。
自アプリだけの呼び出し量では予測しきれない。同じストアの他アプリの消費次第で 429 が返る可能性がある。
アプリ単位や IP 単位ではなく、ストア上の顧客ごとにカウントされる。1 顧客に対する一括処理・ポーリングが要注意パターン。
THROTTLED は恒久エラーではない。即時リトライの連打ではなく Retry-After に従うことが求められている。
開始日・猶予期間、残り枠の確認方法、上限の引き上げ申請可否、Retry-After の値の範囲は記載なし。必要なら Customer Account API のレート制限ドキュメントで確認する。