TRON Energy Rental API: Automate Energy Orders for Exchange Desks and Payouts

Short answer: renting TRON energy through an API means your own service asks for a price, orders energy for a specific address and checks the order status with plain HTTP requests, with nobody clicking buttons in a bot. For an exchange desk, a payment service or a payout bot, it is the way to stop burning TRX on every USDT transfer without keeping an operator on call.

Why you need a TRON energy API

One USDT TRC-20 transfer to an address that already holds USDT takes roughly 64,500-65,000 energy. If the sender has no energy, the network burns about 6.5 TRX instead, and for a transfer to an empty address the figure doubles to around 13 TRX. With a handful of transfers a day that is tolerable. With hundreds, buying energy by hand becomes a bottleneck: somebody has to order it before the transfer, not after.

An API takes the human out of the loop. Before a payout your service asks for a price, places an order for the sending address and only then signs the transfer. Below is how this works at Overtron, which requests you need and where integrations usually break.

Who a TRON energy rental API is for

• exchange desks and P2P services that send USDT to customers automatically;
• payment gateways and processors that pay out in batches;
• payout bots and platforms (affiliate networks, freelance marketplaces, GameFi);
• trading teams with several wallets that need a predictable cost per transfer.

How a TRON energy rental API works

The flow has three steps. Note that energy is not sent to your address like a token: it is delegated, meaning the provider lets you use part of the network resources from its stake for a fixed period.

• Price request. You pass the amount of energy and the rental term and get a quote. It is read-only: it spends nothing and creates nothing.
• Order creation. You pass the address that should receive the energy, the amount and the term. The response contains an order ID and a processing status.
• USDT transfer. Once the energy is delegated to the address, you send the transfer itself, without burning TRX.

Private keys play no part in this flow: an order needs only the public address of the energy recipient. More on why keys are never required is in the article on renting energy without private keys (linked in the security section below).

TRON energy API requests you will need

Overtron's Partner API is small. For the typical scenario of ordering energy before a payout, two methods are enough; the rest are convenient extras.

Price before the order

The quote method takes an amount of energy and a rental term. For an ordinary USDT transfer to an address that already holds the token, people usually request about 65,000 energy. For a transfer to an empty address, plan for roughly double. Do not cache the price for long: the cost of energy follows the market, and a value from an hour ago may no longer match.

Creating an order

An order is created with the energy recipient's address, the amount of energy, the term and the ID of your user in the system. The response returns an order ID and a status, which at creation normally means that the order is being processed. Delegation takes network time: a TRON block lasts 3 seconds, but the provider still has to confirm the operation, so watch the status rather than assume instant execution.

Supporting methods

• user balance and operation history, for reconciling spend;
• the user's latest order, handy for checking the outcome after a failure;
• a deposit address for topping up the balance that pays for orders;
• an IP allowlist for the key, covered in the next section.

Integration security: token, IPs and tracing

The Partner API is protected by a token, passed in the Authorization header as a Bearer token or in X-API-Key. A wrong or missing token returns 403, and it is the most common first-launch mistake: the token was put in the request body, or the word Bearer was forgotten.

• IP allowlist. Requests for a user can be limited to given addresses or subnets (IPv4, IPv6, CIDR). With an empty list the restriction is off; with a filled list, requests from other IPs are rejected. Turn it on for any production service.
• Request ID. Send your own X-Request-ID header: if you do not, the service generates one and returns it. It makes disputed orders easy to find in logs.
• Rate limits. Requests that create something are rate-limited. When you exceed the limit the service answers 429 with a Retry-After header: wait that long instead of hammering retries.

How much energy to order and for how long

Choose the term to match your payout rhythm. If transfers go out every few minutes, very short terms with frequent orders can be awkward, and a longer period or automatic top-up makes more sense. A good check: how many operations will you manage within the term, and will part of the energy go unused?

Common integration mistakes

• Ordering after the transfer. If you send USDT first and order energy later, the network has already burned TRX. The order is strict: order, check the status, transfer.
• Blind retry on timeout. A create-order request may have arrived even if the response was lost. Before repeating a POST, check the user's latest order and store the order ID on your side.
• One energy order for many addresses. Energy is delegated to a specific address. If payouts leave from several addresses, order for each separately.
• No reserve for an empty address. A new recipient needs about double the energy. Underestimating it ends in an out-of-energy failure, which is covered in the OUT_OF_ENERGY article.
• Token in client code. Anyone who sees it can order energy in your name.

What a working payout flow looks like

• Before the payout the service checks whether the recipient already holds USDT and picks the energy amount.
• It requests the price and, if it fits your cost limit, creates an order for the sending address.
• It waits until the order status shows that energy has been delegated.
• It sends the USDT TRC-20 transfer and stores the transaction hash together with the order ID.
• At the end of the day it reconciles the operation history against your accounting.

This cycle is easy to wrap in a task queue: one worker orders energy and another sends transfers. Then a temporary outage in either part never burns TRX; the transfer simply waits its turn.

What to keep in mind

Delivery depends on network conditions and providers, so build waiting and repeated status checks into your code instead of assuming that everything executes at once. We deliberately give no rates in this article: they float with the market, and the live quote comes from the price request at the moment of the order.