Skip to main content

Error format

Errors come back in one of three shapes. Most endpoints use the first one; the other two exist on specific paths and are listed here so your client does not miss an error code it is looking for. Standard. A code for programmatic handling, nested under detail.error:
Account-level rate limit. The same fields, but at the top level, without detail — this response is produced before the request reaches the endpoint:
Flat. The withdrawal verification steps put code next to detail, and detail holds the message itself:
Not every response carries a code. Request validation failures come back in the framework’s own format, where detail is an array of field errors rather than a string, and a few internal checks return {"detail": "..."} with a plain message. Some 422 responses do carry a code in the standard shape — a reused idempotency key, for example.
Read the code from the first of these that is present: detail.error.code, then error.code, then code. Fall back to the HTTP status when none of them is there, and never assume detail is a string: it is an object in the standard shape and an array in a validation error.

HTTP status codes

Common error codes

Returned in the standard shape, under detail.error.code:
Node API (node.tronrental.com) has error codes of its own, in a different format — see Node API → Limits and errors.
INSUFFICIENT_BALANCE is not used everywhere. POST /api/v1/smart-mode/activate and POST /api/v1/transfer-packages/buy report the same condition as 400 with a message and no code: {"detail":{"error":{"message":"Insufficient balance"}}}. On those two endpoints, do not detect a funding problem by the code alone.

Auto Refill codes

Returned in the standard shape by the Auto Refill endpoints:

Withdrawal verification codes

POST /api/v1/account/withdrawal returns these verification codes in the flat shape, with code next to detail. Other errors on the same endpoint use the standard shape:

Retry strategy

Retry 5xx responses with exponential backoff. For 429, prefer the Retry-After header when the response carries one, and check the body first — not every 429 is a rate limit (see Rate Limits).