エラーコードとリトライ指針
API
エラーコード
リトライ
HTTPステータス
この記事の対象
APIエラー処理とリトライロジックを実装する開発者向けです。
APIエラー処理とリトライロジックを実装する開発者向けです。
エラーレスポンスの構造
{
"error": {
"code": "invalid_parameter",
"message": "store_id is required",
"param": "store_id",
"request_id": "req_01HV6N..."
}
}
request_id はサポート問い合わせ時に必須です。エラーログに必ず含めてください。
HTTPステータスコード一覧
| コード | 意味 | リトライ |
|---|---|---|
| 200 OK | 成功 | ― |
| 201 Created | 作成成功 | ― |
| 204 No Content | 成功(本文なし) | ― |
| 400 Bad Request | パラメータ不正 | 不可(修正必要) |
| 401 Unauthorized | 認証失敗 | トークン更新後に1回 |
| 403 Forbidden | 権限不足・スコープ不足 | 不可 |
| 404 Not Found | リソース不在 | 不可 |
| 409 Conflict | 状態競合 | 条件次第 |
| 410 Gone | 廃止済み | 不可 |
| 422 Unprocessable | バリデーションエラー | 不可 |
| 429 Too Many Requests | レート制限 | Retry-After 後 |
| 500 Internal Error | サーバーエラー | 指数バックオフで |
| 502 Bad Gateway | 上流エラー | 指数バックオフで |
| 503 Service Unavailable | 一時的に利用不可 | 指数バックオフで |
| 504 Gateway Timeout | タイムアウト | 指数バックオフで |
主なエラーコード
| code | 対処 |
|---|---|
invalid_parameter | param フィールドの内容を確認 |
missing_parameter | 必須パラメータを追加 |
invalid_token | トークンを更新 |
expired_token | リフレッシュトークンで更新 |
insufficient_scope | 必要スコープを追加して再認可 |
app_not_approved | User系スコープの審査申請が必要 |
resource_not_found | IDの存在確認 |
duplicate_resource | 既存リソースを更新するか別IDで作成 |
rate_limited | Retry-After 秒待機 |
plan_limit_exceeded | プランをアップグレード |
リトライ指針
リトライしてよい条件
- HTTPステータスが
429または5xx - ネットワークタイムアウト・接続エラー
- POSTの場合は
Idempotency-Keyを必ず設定(重複作成を防ぐため)
リトライ間隔(指数バックオフ+ジッター)
function retryDelay(attempt) {
// 1, 2, 4, 8, 16秒(最大32秒)
const base = Math.min(Math.pow(2, attempt), 32);
// ±25%のジッターで集中アクセスを避ける
const jitter = base * (Math.random() * 0.5 - 0.25);
return (base + jitter) * 1000;
}
最大リトライ回数
- 通常API:最大5回
- バッチ処理:最大10回
- ユーザー操作起因:最大2回(待たせすぎない)
429の場合は Retry-After ヘッダーを優先
HTTP/1.1 429 Too Many Requests Retry-After: 30 → 30秒待ってから再試行
リトライしてはいけないケース
4xx(429除く):リクエスト自体に問題があるため、何度試しても同じ- POST/PUTで
Idempotency-Keyを付けていない場合:重複作成のリスク
関連ガイド
公開日: 2026-04-27
更新日: 2026-04-27
カテゴリ
タグ
API (18)
OAuth (12)
Android (8)
Webhook (8)
iOS (7)
api (6)
oauth (5)
トラブル (5)
POS連携 (4)
getting-started (4)
関連記事
-
リクエストとレスポンスの基本(JSON)レシートローラーAPIのリクエスト形式、必須ヘッダー、レスポンス構造、ページネーション、フィルタリング、日時形式の規則を解説します。
-
ネイティブモバイルアプリ向けガイド: 複数ビジネスアカウントアクセスと OAuth フローAndroid / iOS のネイティブアプリ向け実装ガイド。アプリ登録時に「認可時に1つのビジネスアカウントへトークンを紐付ける」をオフにすると、user-scoped OAuth トークンが発行されます。/api/v1/me/organizations + ?organizationId= パターンで複数ビジネスアカウントを横断アクセスできます。
-
取引一覧API(Transactions API:POS+OMS統合フィード)の使い方レシートローラーのTransactions APIは、レジ売上(PosTransactions)と販売管理注文(OmsOrders)を1つのフィードに統合した読み取り専用APIです。Android/iOSアプリで「ビジネスアカウント全体の取引」を一覧表示する際の入り口になります。
-
PosTransactionDto 仕様 — 取引データのフィールドリファレンスレシートローラーが扱う取引データの正規モデル PosTransactionDto の全フィールドを解説します。識別子・日時・金額・明細・支払い・スタッフ・ステータス・CRM 連携の各カテゴリーごとに、フィールド名・型・意味・各 POS ベンダーからの埋め方をまとめた、開発者および外部システム連携担当者向けのリファレンスです。スマレジ・Square 双方のマッピング記事からも参照されます。
-
商品管理API(Products API)の使い方レシートローラーの商品管理API(/api/v1/products)でビジネスアカウント配下の商品をCRUD操作するためのガイドです。Android/iOSアプリやサーバー連携でPIM(商品マスター)を読み書きする際の入門記事です。