Skip to main content
When a request cannot be completed, IteraPay returns an error response with an appropriate HTTP status code. All error responses use the application/problem+json content type and follow the RFC 7807 Problem Details format.

Error response shape

Every error response includes the following fields:
string
A URI that identifies the problem type. You can use this to classify errors programmatically.
string
A short, human-readable summary of the problem type. This does not change between occurrences of the same error type.
integer
The HTTP status code for this occurrence of the problem.
string
A human-readable explanation specific to this occurrence. Use this field when surfacing errors to developers or in logs.
string
A URI reference that identifies the specific occurrence. Typically the request path.

Example error response

Status codes

400 Bad Request

The request body or parameters are invalid. The detail field describes the specific validation failure.

401 Unauthorized

The request is missing credentials, or the provided credentials are invalid. Verify your Authorization header or X-Api-Key header is set correctly.

403 Forbidden

The credentials are valid but the authenticated identity does not have permission to perform this action. This can happen when an API key is used on a merchant it was not issued for, or when your role lacks the required permission.

404 Not Found

The requested resource does not exist. Check that the ID or path is correct.

Other status codes

All other errors use standard HTTP status codes. The type, title, and detail fields in the response body provide additional context.

Handling errors in your code

Check the HTTP status code first, then inspect type for programmatic classification and detail for a human-readable description.
Log the instance field alongside errors in your system. It identifies the exact request path where the problem occurred and makes debugging faster.