能量租赁API对接：两次调用完成报价与下单

简单说：能量租赁 API 让你的后端在每笔出款前自动给转出地址买能量，不需要人工盯着机器人。对接只涉及两个接口：GET /pricing/quote 查询价格，POST /orders 下单代理能量，按收款方情况每笔约 65,000 或 131,000 能量，费用从机器人余额扣除，认证用机器人里生成的 Bearer 密钥。

什么时候需要 API，而不是手动在机器人里下单？

如果每天只有几笔转账，打开机器人手动下单完全够用。问题出在转账由系统触发的时候：兑换商给客户打款、商户退款、支付网关把充值地址里的 USDT 归集到主地址、财务按计划批量付款。这些场景下，构造 USDT 交易的那段代码最清楚“马上要转一笔”，让人工去下单反而成了瓶颈。

钱包和 Telegram 机器人开发者是另一类典型用户。很多用户的 TokenPocket 或 imToken 钱包里只有 USDT、没有 TRX，转账时被提示“TRX 不足”。如果你的产品在用户发起转账前，先通过 API 给用户的地址下一笔能量，用户就能在几乎不持有 TRX 的情况下完成转账，费用由你的产品以自己的方式向用户收取或补贴。整个过程同样只需要用户的公开地址。

不租能量的代价很直接。2026-10-21 网络的能量单价为 100 SUN，一笔转给已持有 USDT 地址的转账约燃烧 6.43 TRX，转给新地址约 13.03 TRX。每月几百笔出款时，燃烧和租用能量之间的差额就是一笔不小的固定开支。企业在钱包结构、记账和资源选择上的整体思路，可以参考企业波场能量方案。

API 包含哪些接口，怎么调用？

两个接口都在请求头 Authorization 里使用 Bearer 密钥认证。API 基础地址和密钥都在机器人的 API 菜单里获取。

一个最小的调用流程如下：

# 1. 查询报价（只读）
GET {API_BASE}/pricing/quote?energy_amount=65000&duration_minutes=60
Authorization: Bearer <api_key>

# 2. 给转出地址下单能量
POST {API_BASE}/orders
Authorization: Bearer <api_key>
Content-Type: application/json

{
  "receive_address": "T…",
  "energy_amount": 65000,
  "duration_minutes": 60
}

下单返回的结果里包含订单 ID 和状态。建议把订单 ID 和对应的出款记录存在一起，方便之后对账。接口说明和接入步骤也可以在机器人的 API 栏目查看。

租期和能量数量该怎么选？

租期以分钟为单位传入，可选 15 分钟、1 小时、1 天和 3 天，对应 duration_minutes 为 15、60、1440、4320。原则是选“能安全覆盖从下单到广播交易这段时间”的最短租期：

• 15 分钟：单笔出款，交易构造好后立刻广播。
• 1 小时：出款需要排队，或者要等人工审核。
• 1 至 3 天：热钱包持续出款，宁愿一次下单省事。

能量数量取决于收款方，与转账金额无关。转 10 USDT 和转 10,000 USDT 消耗的能量一样。

差异来自 USDT 合约为新持有人写入余额记录所需的额外运算。实际消耗还会受波场动态能量机制影响，热门合约在高峰期消耗更多。能量的计量方式见官方的资源模型文档。

怎样把 API 嵌进出款流程？

大多数出款系统可以套用下面的顺序：

1. 查询收款方的 USDT 余额。 通过自己的节点或公开接口读取。余额为零就按约 131,000 下单，否则按约 65,000。
2. 报价（可选）。 不必每笔都查，但如果你想记录预计成本，或者给单笔能量设置价格上限，可以先调一次。
3. 下单。 给转出地址下单，租期覆盖排队时间。
4. 等待代理到账。 读取订单状态，再轮询转出地址的资源，确认代理能量已经出现。设置一个较短的超时加重试即可，正常情况下几秒内就能确认。
5. 广播 USDT 转账。 合理设置 fee_limit，这样万一能量不足，交易会失败，而不是悄悄燃烧一大笔 TRX。
6. 对账。 把订单 ID、转账哈希和实际消耗的能量对应起来。在 Tronscan 的交易详情页可以看到消耗的能量和燃烧的 TRX。

特别注意第 3 步里的地址是转出方，也就是付手续费、发起合约调用的那个钱包。把能量下到收款方地址，对你的出款毫无作用。

另外别忘了带宽。一笔 USDT 转账约 345 字节，每个激活地址每天有 600 点免费带宽。出款频繁的热钱包很快会用完免费额度，之后每笔约燃烧 0.35 TRX，所以热钱包上要保留少量 TRX。

接入调试时常见哪些问题？

建议按“先只读、后小额”的顺序调试。报价接口不扣费，可以反复调用，确认认证头、参数格式和返回结构都没问题。之后用少量余额下一笔真实订单，最小订单是一笔转账所需的能量，再用一笔小额 USDT 转账走完整个流程。

调试阶段最常碰到的情况有这么几种：

• 地址未激活。 新生成的地址在链上还没有账户，无法接收代理的能量。给一批新充值地址下单前，先确认它们已经激活，比如已经收到过 TRX 或代币。
• 能量下错了地址。 把能量下到了收款方，转出方仍然没有能量，交易照样燃烧 TRX。代码里要明确区分“发款地址”和“收款地址”两个变量。
• 余额不足。 API 订单和机器人订单共用同一个余额，人工下单也会消耗它。建议在自己的监控里加一个余额阈值提醒。
• 钱包预估滞后。 有些钱包或 SDK 的手续费预估在能量刚到账时还没刷新，显示仍要燃烧 TRX。以链上读取到的资源为准，而不是以预估为准。
• 租期太短。 交易在队列里等待超过 15 分钟，能量已经到期回收。排队时间不确定时，用 1 小时更稳妥。

以归集为例算一笔账：假设每天要从 100 个充值地址把 USDT 归集到主地址，主地址已经持有 USDT，每笔约需 65,000 能量。全部燃烧的话，按 2026-10-21 的参数约为 100 × 6.43 = 643 TRX；用 API 为每个充值地址下单，就只需支付租金，另加各地址自身的带宽开销。实际能省多少取决于当时的市场价格，可以先用报价接口按自己的数量查一下。

密钥和余额怎么保管才安全？

API 密钥可以动用账户余额，应当像数据库密码一样对待：

• 只放在服务器端。 不要写进移动端 App、前端代码或公开的代码仓库。
• 用环境变量或密钥管理工具保存。 不要写进纳入版本控制的配置文件。
• 有怀疑就更换。 机器人里可以随时注销旧密钥、重新生成。
• 控制余额规模。 按几天的预计用量充值，而不是一次充几个月。万一密钥泄露，损失也有上限。
• 下单前校验地址。 receive_address 写错一个字符，能量就会发到一个用不上的地址。

整个对接过程中，API 只需要公开地址，不接触任何钱包私钥。这也是它适合冷热分离、签名机独立部署架构的原因：下单的服务器和签名的机器可以完全隔离。

API 不适合哪些场景？

如果是同一个地址每天多次转 USDT，而且时间大致固定，每笔都调 API 下单可能反而麻烦。自动能量补充（智能模式）会在地址上常备约 131,000 能量，每笔转账后自动补足，你这边不需要写任何调用代码。

不少团队两者结合使用：主热钱包开智能模式，偶尔从充值地址归集时再用 API 单独下单。转出地址经常变化、出款时间不规律，或者需要把每一笔能量开支精确对应到自己账本里的某笔交易时，API 是更合适的工具。