Error codes and retry guidance
API
Error codes
Retry
HTTP status
Who this article is for
For developers implementing API error handling and retry logic.
For developers implementing API error handling and retry logic.
Structure of an error response
{
"error": {
"code": "invalid_parameter",
"message": "store_id is required",
"param": "store_id",
"request_id": "req_01HV6N..."
}
}
request_id is required when contacting support. Always include it in your error logs.
HTTP status codes
| Code | Meaning | Retry |
|---|---|---|
| 200 OK | Success | — |
| 201 Created | Created successfully | — |
| 204 No Content | Success (no body) | — |
| 400 Bad Request | Invalid parameter | No (fix needed) |
| 401 Unauthorized | Authentication failed | Once, after refreshing the token |
| 403 Forbidden | Insufficient permission / scope | No |
| 404 Not Found | Resource does not exist | No |
| 409 Conflict | State conflict | Depends on the situation |
| 410 Gone | Discontinued | No |
| 422 Unprocessable | Validation error | No |
| 429 Too Many Requests | Rate limited | After Retry-After |
| 500 Internal Error | Server error | With exponential backoff |
| 502 Bad Gateway | Upstream error | With exponential backoff |
| 503 Service Unavailable | Temporarily unavailable | With exponential backoff |
| 504 Gateway Timeout | Timeout | With exponential backoff |
Main error codes
| code | What to do |
|---|---|
invalid_parameter | Check the value of the param field |
missing_parameter | Add the required parameter |
invalid_token | Refresh the token |
expired_token | Refresh with the refresh token |
insufficient_scope | Add the required scope and re-authorize |
app_not_approved | Review application for the User-scope is needed |
resource_not_found | Check the ID exists |
duplicate_resource | Update the existing resource or create with a different ID |
rate_limited | Wait Retry-After seconds |
plan_limit_exceeded | Upgrade the plan |
Retry guidance
Conditions safe to retry
- HTTP status is
429or5xx - Network timeout / connection error
- For POST, always set an
Idempotency-Key(to prevent duplicate creation)
Retry interval (exponential backoff + jitter)
function retryDelay(attempt) {
// 1, 2, 4, 8, 16 seconds (max 32)
const base = Math.min(Math.pow(2, attempt), 32);
// ±25% jitter to avoid a thundering herd
const jitter = base * (Math.random() * 0.5 - 0.25);
return (base + jitter) * 1000;
}
Maximum retry counts
- Regular API: up to 5 times
- Batch processing: up to 10 times
- Triggered by user action: up to 2 times (don't keep them waiting)
For 429, prioritize the Retry-After header
HTTP/1.1 429 Too Many Requests Retry-After: 30 → Wait 30 seconds, then retry
Cases you must not retry
4xx(except 429): there is a problem with the request itself, so retrying gives the same result- POST/PUT without an
Idempotency-Key: risk of duplicate creation
Related guides
Published: 2026-04-27
Updated: 2026-07-05
Category
Tags
API (22)
OAuth (15)
Android (10)
iOS (9)
Webhook (6)
Troubleshooting (5)
api (5)
App registration (4)
POS Integration (4)
Reference (4)
Related articles
-
Using the Store Information APIA guide to the REST API for fetching and updating a store's basic information (store name, store type, contact details, and address). Lets you implement a store information editing screen from token-authenticated clients such as staff apps.
-
PosTransactionDto specification — field reference for transaction dataA complete field reference for PosTransactionDto, the canonical model for the transaction data ReceiptRoller handles. For each category — identifiers, dates, amounts, line items, payments, staff, status, and CRM linkage — it summarizes the field names, types, meanings, and how each POS vendor populates them. A reference for developers and external-system integrators. Also referenced from the Smaregi and Square mapping articles.
-
Purchase and receipt data integrationExplains the structure of the purchase and receipt data ReceiptRoller handles, how to retrieve it, related scopes, Webhooks, and common use cases.
-
Using the Business Hours APIA guide to ReceiptRoller's Business Hours API (/api/v1/stores/{storeId}/business-hours). Covers retrieving and updating per-day business hours, registering special business days (temporary closures and hour changes), configuring a store's workable hours (the upper bound for shift creation), and determining whether the store is currently open.
-
Using the Orders / OMS APIA guide to CRUD operations on the orders under a business account using ReceiptRoller's Orders / OMS API (/api/v1/orders). Covers creating, updating, transitioning status (confirm, process, cancel), and deleting orders, plus the flow for Android / iOS apps and server integrations.