レート制限とスロットリング
API
レート制限
429
スロットリング
リトライ
レシートローラーのAPIで、リクエスト数の制限がかかるのはどこか、制限に達したときに何が返るか、制限がなくてもクライアント側でどう流量を抑えるべきかをまとめます。アプリのアクセストークンで呼ぶ店舗・ビジネスアカウント向けのAPIには、現在リクエスト数の制限はありません。制限があるのは、レシートの受け取りや端末からの送信など、一部の個別のエンドポイントだけです。
アプリのトークンで呼ぶAPI
- 商品・売上・予約など、アクセストークンで呼ぶ
/api/v1/...のエンドポイントには、リクエスト数の上限も、プラン別の上限や1日あたりの上限もありません。 - そのため、
X-RateLimit-Limit・X-RateLimit-Remaining・X-RateLimit-Resetのようなレート制限ヘッダーは返りません。 - トークンエンドポイント
POST /api/v1/auth/tokenも、認可コード(authorization_code)とリフレッシュトークン(refresh_token)の交換には制限がありません。
上限がないからといって、どれだけ並列に送ってもよいわけではありません。後述の「クライアント側での流量の抑え方」に沿って実装してください。
個別に制限があるエンドポイント
次のエンドポイントには、直近1分間(メールは1時間)のリクエスト数に上限があります。数えるのは送信元のIPアドレス単位、または表の「数える単位」の組み合わせごとです。
| エンドポイント | 上限 | 数える単位 |
|---|---|---|
POST /api/v1/devices/printer/receipts、POST /api/v1/devices/printer/receipts/{token}/ad-printed | 300回/分 | IPアドレス |
GET /api/v1/apps/{shopId}/ads | 30回/分 | IPアドレス |
GET /api/v1/receipt-ad | 60回/分 | IPアドレス |
GET /api/v1/terminals/{publicTerminalId}/last-receipt、GET /api/v1/rx/{claimToken} | 10回/分 | IPアドレスと端末(またはトークン)の組 |
POST /api/v1/terminals/{publicTerminalId}/claim、POST /api/v1/rx/{claimToken}/claim | 3回/分(上の10回/分にも数えます) | IPアドレスと端末(またはトークン)の組 |
POST /api/v1/user/terminals/{publicTerminalId}/claim、POST /api/v1/user/rx/{claimToken}/claim | 3回/分 | IPアドレスと端末(またはトークン)の組 |
POST /api/v1/rx/{claimToken}/claim でメール受け取りを選んだとき | 3回/時 | 送り先メールアドレス |
勤怠の打刻(POST /api/v1/stores/{storeId}/timecards/punch)は、レート制限ではありませんが、同じ人の PIN を5回続けて間違えるとその人の打刻が15分間止まり、429 と {"error": "pin_locked", "message": "...", "lockedUntil": "..."} が返ります。
このほか、レシートローラー公式アプリのサインイン用の処理(IDトークンの交換や匿名アカウントの作成)にも独自の制限がありますが、開発者アプリが使う認可コードとリフレッシュトークンの交換には関係しません。
制限に達したときのレスポンス
ステータスは 429 Too Many Requests です。返り方はエンドポイントによって2通りあります。
- プリンター送信(
/api/v1/devices/printer/...)、GET /api/v1/apps/{shopId}/ads、各.../claimの3回/分の制限では、Retry-After: 60ヘッダーと、本文として次のテキストToo many requests. Please try again in a minute.が返ります。 - それ以外の制限(
last-receipt、GET /api/v1/rx/{claimToken}、GET /api/v1/receipt-ad、claim の10回/分、メールの3回/時)では、本文もRetry-Afterもない429が返ります。
HTTP/1.1 429 Too Many Requests
Retry-After: 60
Too many requests. Please try again in a minute.
JSON の本文やエラーコードはありません。429 はステータスコードで判定してください。
クライアント側での流量の抑え方
- 一括処理は1件ずつ順番に送ります。
Promise.allなどで数百件を同時に送らないでください。 - 一覧系のAPIを使い、1件ずつの取得を繰り返さないようにします。たとえば商品一覧
GET /api/v1/productsは全件を1回で返すので、同期では一度取得して手元で照合します。 - 変わりにくいデータ(店舗、商品マスタ)は手元にキャッシュします。
- 変化を知るためのポーリングより Webhook を使います(Webhookで新しい売上を受け取り、Slackに通知する)。
リトライの方針
429:Retry-Afterがあればその秒数待ってから送り直します。ない場合も、制限は直近1分間で数えるため、1分ほど待ってから送り直します。503などの5xx、タイムアウト、接続エラー:間隔を倍々に広げ、ゆらぎ(ジッター)を加えて数回まで送り直します。400・401・403・404:同じリクエストを送り直しても結果は変わりません。401はトークンを更新してから1回だけ送り直します。- 作成の
POSTをタイムアウト後に送り直すと、二重に作成されることがあります。共通のIdempotency-Keyヘッダーはないため、送り直す前に一覧などで作成済みかどうかを確認してください。
async function callWithRetry(send, maxAttempts = 5) {
for (let attempt = 1; ; attempt++) {
const response = await send();
const retryable = response.status === 429 || response.status >= 500;
if (!retryable || attempt === maxAttempts) return response;
const retryAfter = Number(response.headers.get("Retry-After"));
const backoff = Math.min(2 ** attempt, 60) * (0.75 + Math.random() * 0.5);
const waitSeconds = response.status === 429 ? (retryAfter || 60) : backoff;
await new Promise((resolve) => setTimeout(resolve, waitSeconds * 1000));
}
}
関連情報
公開日: 2026-04-27
更新日: 2026-10-26
カテゴリ
タグ
API (26)
OAuth (21)
Android (13)
iOS (12)
Webhook (9)
api (6)
oauth (5)
クイックスタート (5)
トラブル (5)
Node.js (4)
関連記事
-
店舗情報API(Store Information API)の使い方店舗の基本情報(店舗名・店舗種別・連絡先・住所)を取得・更新する REST API のガイドです。スタッフアプリなどのトークン認証クライアントから店舗情報の編集を実装できます。
-
定期予約・出欠・キャンセル待ちAPI の使い方レシートローラーの定期予約API(/api/v1/reservations/series)、出欠・振替API(/api/v1/reservations/attendance)、キャンセル待ちAPI(/api/v1/reservations/waitlist)のガイドです。毎週の定期予約の登録と生成、クラスの出欠記録、振替の受付、キャンセル待ちの管理を解説します。
-
営業時間API(Business Hours API)の使い方レシートローラーの営業時間API(/api/v1/stores/{storeId}/business-hours)のガイドです。曜日ごとの営業時間の取得・更新、特例営業日(臨時休業・営業時間変更)の登録、店舗の就業可能時間(シフト作成時の上限となる業務時間)の設定、現在営業中かどうかの判定までを解説します。
-
リクエストとレスポンスの基本(JSON)レシートローラーAPIのリクエスト形式、必須ヘッダー、レスポンス構造、ページネーション、フィルタリング、日時形式の規則を解説します。
-
ネイティブモバイルアプリ向けガイド: 複数ビジネスアカウントアクセスと OAuth フローAndroid / iOS のネイティブアプリ向け実装ガイド。アプリ登録時に「認可時に1つのビジネスアカウントへトークンを紐付ける」をオフにすると、user-scoped OAuth トークンが発行されます。/api/v1/me/organizations + ?organizationId= パターンで複数ビジネスアカウントを横断アクセスできます。