Business errors can use the following envelope. Authentication and rate-limit responses may instead contain a flat error string; response shape depends on the deployed path. The safe error wrapper handles both without logging upstream text:
{
"error": {
"code": "E2001",
"type": "game_not_found",
"message": "Game Not Found",
"details": {}
}
}
Field
Type
Description
code
string
Stable error code (e.g., E2001). Use this for programmatic handling.
type
string
Snake-case name derived from the error enum. Treat the received value as untrusted; log only a recognized code.
message
string
Human-readable description. May include additional context.
details
object
Optional. Extra context such as field names, limits, or identifiers. Present only when relevant.
Errors related to wallet callbacks and financial operations.
Code
Type
HTTP
Description
Operator Action
E4001
insufficient_balance
402
Player balance is too low for this bet amount.
Decline the bet with 402 (or HTTP 200 + body {"status": 402, ...}) and return the current balance in your callback response. The platform shows an insufficient-funds message to the player.
E4002
duplicate_transaction
200
This scoped transaction has already been processed (idempotent retry).
Replay the original response stored for this integration/organization, provider_code and transaction_id identity — same HTTP status (200 for a settled transaction) and body. Do not return 409 or re-process the transaction.
E4003
amount_exceeds_limit
400
Bet amount exceeds the configured maximum.
Check your operator limits. The details field includes the current limit.
E4004
invalid_amount
400
Amount is invalid for the transaction contract; supported zero-win settlements may use zero.
Validate the request amount against the transaction/provider contract.
E4005
loss_limit_exceeded
400
Player has hit their loss limit for the configured period.
The platform enforces this automatically. Do not allow further bets until the period resets.
Errors related to API key authentication, HMAC signature verification, and account deletion.
Code
Type
HTTP
Description
Operator Action
E5001
callback_signature_invalid
401
HMAC signature verification failed on a callback request.
Verify you are using the correct callback_secret and signing the request body correctly. See the signature verification guide.
E5002
api_key_invalid
401
API key is not recognized.
Check that you are sending the correct key in the Authorization header. Send the issued credential unchanged and confirm its status and deployment policy.
E5003
api_key_expired
401
API key has expired.
If your deployment returns this code, follow its credential replacement procedure; do not assume an expired key remains accepted.
E5004
scope_insufficient
403
This API key does not have permission for the requested operation.
Check the scopes assigned to your key. You may need a key with broader permissions.
E5020
deletion_blocked
409
Account deletion is blocked (active sessions or pending transactions).
Resolve all pending operations before requesting deletion.
E5021
deletion_failed
500
Account deletion encountered an unexpected error.
Retry or contact support.
E5022
deletion_token_invalid
400
The deletion confirmation token is invalid.
Request a new deletion token.
E5023
deletion_token_expired
400
The deletion confirmation token has expired.
Request a new deletion token and confirm within the time window.
These only occur on platform accounts — a partner whose single API key acts
on behalf of several casino brands (“sub-operators”). Every operator-scoped call
takes an optional sub_operator_ref naming the brand it acts as. An ordinary
operator key never sees these.
Code
Type
HTTP
Description
Operator Action
E6004
sub_operator_ref_invalid
400
sub_operator_ref is malformed — or was sent empty.
Use 1–32 characters of [A-Za-z0-9_-], starting and ending alphanumeric. To use your default brand, omit the field entirely; sending it blank is an error, not a fallback.
E6005
sub_operator_required
400
The field was omitted, and this platform is configured with require_sub_operator_ref.
Name the brand on every call. This mode is opt-in — a platform running many brands can ask for a loud failure instead of a default.
E6006
sub_operator_not_allowed
400/403
sub_operator_ref was sent from a key that is not a platform key.
Remove the field. Your key already identifies a single operator.
E6007
sub_operator_limit
400
This platform is at its brand cap.
Contact The Aggregator support to raise the cap.
E6008
sub_operator_unknown
400
An unseen ref, and auto-provisioning is disabled for this platform.
Create the brand first with POST /v1/sub-operators, or ask support to enable auto-provisioning.
E6009
platform_not_provisioned
409
The platform account is not fully set up and owns no organization to bill.
Contact The Aggregator support.
E6010
platform_default_missing
409
A call omitted sub_operator_ref and this platform has no default brand.
Create your first brand with POST /v1/sub-operators — the first one created becomes the default. A brand is never minted on the money path.
Retry with exponential backoff. If the error persists for more than 5 minutes, contact support with the HTTP status, recognized error code, and a correlation ID generated by your application.
E0002
database_error
503
Database connectivity issue. This is transient.
Retry after a short delay. These errors typically resolve within seconds.
Match on code, not message. The message field may change between versions. The code field is stable.
Log safe diagnostics. Record the HTTP status and only error codes your application explicitly recognizes; map unexpected codes to a fixed label. The response body, message, and details may contain sensitive data: keep them out of logs. When contacting support, include a correlation ID generated by your application.
Retry transient errors. Codes E0001, E0002, E1002, E1053, and E1054 are transient. Use exponential backoff with jitter.
Do not retry 4xx errors. Client errors (400, 401, 402, 403, 404, 409) indicate a problem with the request (or, for 402, a declined bet). Fix the request before retrying.
Respect rate limit headers. Use supplied Retry-After and X-RateLimit-* values; retry only when the operation’s idempotency contract permits it.
Handle E4002 (duplicate) gracefully. This is expected in idempotent retry flows. Return the same response you returned for the original transaction.