TRON Energy API: Quote and Order Energy in Two Calls

In short: a TRON energy API lets your backend buy energy for any address without a person in the loop. With EnergyTRX it is two authenticated calls, GET /pricing/quote for the price and POST /orders to delegate energy, usually about 65,000 or 131,000 units per USDT transfer depending on the recipient. Payment comes from your bot balance.

Who needs a TRON energy API rather than a bot?

The bot is fine when a person sends a few transfers a day. It stops scaling once transfers are triggered by your own system: customer withdrawals on an exchanger, refunds at a merchant, sweeps from deposit addresses, scheduled payroll. In each case the code that builds the USDT transaction should also make sure the energy is there, because a human ordering it by hand becomes the bottleneck.

Without energy, each transfer burns TRX. On 21.10.2026, at 100 SUN per unit, that is about 6.43 TRX to a regular recipient and about 13.03 TRX to a new one. Across hundreds of payouts a month, the gap between burning and renting energy becomes a line item. The wider business picture, including accounting and wallet layout, is in TRON energy for business.

How does the EnergyTRX API work?

There are two calls, and both use a Bearer key in the Authorization header. The base URL and the key are issued in the bot's API section.

A minimal flow looks like this:

# 1. Quote (read-only)
GET {API_BASE}/pricing/quote?energy_amount=65000&duration_minutes=60
Authorization: Bearer <api_key>

# 2. Order energy for the address that will send USDT
POST {API_BASE}/orders
Authorization: Bearer <api_key>
Content-Type: application/json

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

The order response returns an order ID and a status. Store the ID next to the payout it belongs to, so you can reconcile charges against transfers later. The API section of the bot shows the same contract along with connection steps.

Which terms and amounts should you request?

The term is set in minutes. The service offers 15 minutes, one hour, and day-long terms of one to three days; on the site those map to duration_minutes values of 15, 60, 1440 and 4320. Pick the shortest term that safely covers the time between ordering and broadcasting:

• 15 minutes for a single payout built and sent straight away.
• 60 minutes when a payout waits in a queue or needs manual approval.
• 1 to 3 days for a hot wallet that sends steadily and where you'd rather order once.

The amount depends on the recipient, not on the size of the payment. Sending 10 USDT or 10,000 USDT costs the same energy.

The difference comes from the USDT contract writing a new balance slot for a fresh holder. The live consumption also shifts with TRON's dynamic energy model, which can raise the cost of popular contracts. The resource model documentation explains how energy is counted.

How do you wire the API into a payout pipeline?

A pattern that works for most payout systems:

1. Read the recipient's USDT balance through your TRON node or a public API. Zero means order about 131,000; non-zero means about 65,000.
2. Quote. Optional for every payout, but useful when you want to log the expected cost or refuse orders above a price ceiling.
3. Order energy for the sending address with a term that covers your queue time.
4. Wait for delegation. Read the status in the order response, then poll the sending address's resources until the delegated energy shows up. A short timeout with a retry is enough; delegation is normally confirmed within seconds.
5. Broadcast the USDT transfer with a sensible fee_limit, so that if energy is short the transaction fails instead of quietly burning a large amount of TRX.
6. Reconcile. Match the order ID, the transfer hash and the energy consumed. The transfer's details on Tronscan show energy used and any TRX burned.

Note the address in step 3 is the sender, the wallet that pays for the contract call. Energy on the recipient's address does nothing for your payout.

How do you keep the API key and balance safe?

An API key can spend your balance, so treat it like a database password.

• Server-side only. Never ship the key in a mobile app, a browser bundle or a public repository.
• Environment variables or a secrets manager, not a config file in version control.
• Rotate on suspicion. The bot lets you revoke a key and issue a new one at any time.
• Cap the balance. Top up for a few days of expected volume rather than months ahead. A compromised key can then only burn through what's there.
• Validate addresses before ordering. A typo in receive_address sends energy to an address that won't use it.

None of this touches your wallets' private keys. The API needs only public addresses, which is also why it fits custody setups where signing happens on a separate machine.

When is the API not the right tool?

If one address sends USDT many times a day at roughly predictable hours, ordering per payout can be more work than it's worth. Automatic TRON energy, the smart mode, keeps about 131,000 energy on the address and refills it after each transfer without any calls from your side. Some teams combine both: smart mode on the main hot wallet, API orders for occasional sweeps from deposit addresses.

The API is the better fit when the sending addresses change, when payouts are irregular, or when you need each energy purchase tied to a specific transaction in your own ledger.