跳转到主要内容

错误格式

错误以三种形式之一返回。多数端点使用第一种;另外两种出现在特定路径上,此处一并列出,以免您的客户端 漏掉正在查找的错误代码。 标准形式。 用于程序化处理的 code,嵌套在 detail.error 中:
账户级速率限制。 字段相同,但位于顶层且没有 detail——该响应在请求到达端点之前就已生成:
扁平形式。 提现验证步骤把 code 放在 detail 旁边,而 detail 中直接是消息本身:
并非每个响应都带代码。请求校验失败采用框架自身的格式,其中 detail 是字段错误的数组而非字符串; 少数内部检查返回带纯文本消息的 {"detail": "..."}。而有些 422 响应确实带代码,且采用标准形式——例如 重复使用的幂等键。
按以下顺序读取第一个存在的字段:detail.error.code,其次 error.code,再次 code。三者都不存在时 以 HTTP 状态码为准;并且切勿假定 detail 是字符串——标准形式中它是对象,校验错误中它是数组。

HTTP 状态码

常见错误代码

以标准形式返回,位于 detail.error.code:
Node API(node.tronrental.com)有自己的错误代码,格式也不同——参见 Node API → 限制与错误。
INSUFFICIENT_BALANCE 并非处处适用。POST /api/v1/smart-mode/activate 和 POST /api/v1/transfer-packages/buy 会把同样的情况报成 400,只带消息、不带代码: {"detail":{"error":{"message":"Insufficient balance"}}}。在这两个端点上,请勿仅凭代码判断余额不足。

自动补充代码

自动补充端点以标准形式返回:

提现验证代码

POST /api/v1/account/withdrawal 以扁平形式返回这些验证代码,code 与 detail 并列;该端点的其他 错误则使用标准形式:

重试策略

对 5xx 响应采用指数退避重试。对 429,当响应带有 Retry-After 头时优先使用它,并先读取响应体—— 并非所有 429 都是速率限制(参见速率限制)。