Skip to main content
The SmartRetry API uses standard HTTP status codes and serializes documented failures using the shared error body below. Use reason_code as the machine-readable identifier and retain detail for diagnostics.

Error response structure

All error responses share this shape:
string
required
Identifies the error category.
string
required
A short, human-readable summary of the error.
integer
required
The HTTP status code for this response (e.g., 400, 401, 404).
string
required
A detailed description of what went wrong in this specific request. Use this field for debugging and logging.
string
Identifies the request associated with this occurrence when available.
string
required
A machine-readable code identifying the failure cause. Use this for programmatic error handling and branching logic.
object
Optional error-specific data. Its properties vary by error.

HTTP status codes

Status codes by operation

This matrix lists all non-success responses declared by each published operation. Authentication and rate-limiting guidance above is maintained separately and does not add undeclared responses to an operation.

Reason codes

Example error responses

The values below illustrate the shared response shape. A specific detail, reason_code, or context value is not guaranteed unless the endpoint contract declares it.

Handling errors in production

Use reason_code rather than detail or title for programmatic handling. Human-readable fields may change.
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 ROUTING/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 ROUTING/IDEMPOTENCY_CONFLICT, do not retry with the same key and a different body. Generate a new Idempotency-Key for a new operation.
Transaction outcomes A successful submission response confirms that the operation was accepted for processing. Use the Transaction status operation to retrieve the current payment outcome.
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.