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:A URI reference that identifies the error type. Points to documentation for the specific problem category.
A short, human-readable summary of the error. Does not change between occurrences of the same error type.
The HTTP status code for this response (e.g.,
400, 401, 404).A detailed description of what went wrong in this specific request. Use this field for debugging and logging.
A URI that identifies this specific occurrence of the error. Include this in support requests when available.
A machine-readable code identifying the failure cause. Use this for programmatic error handling and branching logic.
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.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 theRetry-Afterresponse header before retrying. Do not retry immediately.503 Service Unavailable- if the reason code isRESOURCE_LOCKED, retry the same POST request shortly with the sameIdempotency-Key.
400 Bad Request- fix the request before retrying. Check thecontext.fieldvalue to identify which field is invalid.401 Unauthorized- verify your API key is correct and present in thex-api-keyheader.403 Forbidden- the key is valid but not authorized for this terminal. Check you are using the rightterminal_friendly_id.409 Conflict- if the reason code isIDEMPOTENCY_CONFLICT, do not retry with the same key and a different body. Generate a newIdempotency-Keyfor a new operation.
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.