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
A URI identifying the error type, in the form https://terminal.smartretry.com/errors/<reason_code>.
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

This is a curated shortlist of common codes. See Status reason codes for the full catalog, including all decline and processor-level reasons.

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 - check the reason_code, then verify your x-timestamp and x-signature headers. See Authentication.
  • 403 Forbidden - the API Secret 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.
Retryable conflicts
  • 409 Conflict with ROUTING/RESOURCE_LOCKED - another operation holds the lock on the order or recurring series. Retry after a short backoff.
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.