Skip to main content
The SmartRetry API uses standard HTTP status codes and returns a consistent error body on every failure. Parse the reason_code field for programmatic error handling - it identifies the specific failure cause regardless of which endpoint you called.

Error response structure

All error responses share this shape:
type
string
required
A URI reference that identifies the error type. Points to documentation for the specific problem category.
title
string
required
A short, human-readable summary of the error. Does not change between occurrences of the same error type.
status
integer
required
The HTTP status code for this response (e.g., 400, 401, 404).
detail
string
required
A detailed description of what went wrong in this specific request. Use this field for debugging and logging.
instance
string
A URI that identifies this specific occurrence of the error. Include this in support requests when available.
reason_code
string
required
A machine-readable code identifying the failure cause. Use this for programmatic error handling and branching logic.
context
object
Additional structured data about the error, such as which field failed validation or the conflicting transaction ID. Contents vary by error type.

HTTP status codes

Reason codes

Example error responses

Handling errors in production

Always branch on reason_code, not on detail or title. The human-readable fields may change; reason_code values are stable across API versions.
Retryable errors
  • 500 Internal Server Error - retry with exponential backoff. Check status.smartretry.com if errors persist beyond a few minutes.
  • 429 Too Many Requests - wait for the number of seconds in the Retry-After response header before retrying. Do not retry immediately.
  • 503 Service Unavailable - if the reason code is RESOURCE_LOCKED, retry the same POST request shortly with the same Idempotency-Key.
Non-retryable errors
  • 400 Bad Request - fix the request before retrying. Check the context.field value to identify which field is invalid.
  • 401 Unauthorized - verify your API key is correct and present in the x-api-key header.
  • 403 Forbidden - the key is valid but not authorized for this terminal. Check you are using the right terminal_friendly_id.
  • 409 Conflict - if the reason code is IDEMPOTENCY_CONFLICT, do not retry with the same key and a different body. Generate a new Idempotency-Key for a new operation.
Declined transactions A declined transaction returns 200 OK with "accepted": false in the response body - this is not an error response. Do not confuse payment declines with API errors. Log the transaction status and handle the decline according to your retry strategy.
Log the full error response body for every non-2xx status, including instance when present. This makes it significantly faster to diagnose issues with SmartRetry support.