Error response format
All errors follow a consistent structure:Error fields
code: Machine-readable error codemessage: Human-readable error messagestatus: HTTP status codepath: API endpoint that generated the errortimestamp: When the error occurredrequestId: Unique request identifier for supportdetails: Additional error-specific information
HTTP status codes
| Code | Description | Common causes |
|---|---|---|
400 | Bad Request | Invalid input, validation errors |
401 | Unauthorized | Missing or invalid API key |
403 | Forbidden | Insufficient permissions |
404 | Not Found | Resource doesn’t exist |
409 | Conflict | Duplicate resource, invalid state |
500 | Internal Server Error | Server-side error |
502 | Bad Gateway | Provider integration error |
Common error codes
VALIDATION_ERROR (400)
Input validation failed. Check thedetails.issues array for specific field errors.
Card credential fields (
card_data.number, card_data.cvv, card_data.network_token, card_data.cryptogram, and the 3DS card.number) are accepted only as encrypted values from rinne-js. A plaintext value triggers a per-field VALIDATION_ERROR issue telling you to send the encrypted value from rinne-js instead. The rejected value is never echoed back in the error response.AUTHENTICATION_ERROR (401)
API key is missing or invalid.x-api-key header.
AUTHORIZATION_ERROR (403)
You don’t have permission to access the resource.RESOURCE_NOT_FOUND (404)
The requested resource doesn’t exist.CONFLICT_ERROR (409)
Resource already exists or operation conflicts with current state.INTEGRATION_ERROR (502)
Provider integration failed.requestId.
Handling validation errors
Validation errors include detailed information about each invalid field:Idempotency
Use therequest_id field to safely retry requests:
Rate limiting
Rinne applies request rate limits to keep the platform stable: 1000 req/s for transaction creation and 3DS session creation and authenticationPOST requests and 50 req/s for all other requests. Each limit is a shared pool across all matching endpoints, not a per-endpoint allowance. Requests within the limit always succeed; only the excess requests above the limit are rejected, with no account block or penalty. See the Rate limits guide for full details.
Rejected requests return a 429 Too Many Requests status code with no response body. The limit details are returned in the response headers instead:
429 status code and the x-ratelimit-* headers, not from a response body. Implement exponential backoff when retrying:
Logging and debugging
Request IDs
Every response includes arequestId that you can use when contacting support:
Error monitoring
Implement error monitoring to track API errors:Next steps
Webhooks
Handle webhook delivery failures
API Reference
View all error response schemas

