Rent Tron energy from an API when you pay people in USDT

Short answer

Check the transfer, then order 65,000 or 131,000 energy onto the wallet that will sign, for 15 minutes or an hour. The order does not include a price. The Tron energy rental API charges the lowest offer and takes it from TRX you have already deposited. When the delegation is in place, you send the USDT.

The hand version does not survive a hundred payouts

Doing this on a website is fine for one payment. For a payout run it means opening a tab, paying, waiting, then going back to the signer, a hundred times, while TRX burns on every transfer you were too late for. The API is the same rental the site sells. A script can ask, pay, and wait.

The loop is short enough to hold in your head. You know who you are about to pay. You ask how much energy that one transfer needs, for that sender and that recipient, because the recipient's USDT balance changes the answer. You order the energy onto the address that will sign. You wait until the order is filled. Then you broadcast the USDT. You never put a TRX price in the order. The service picks the cheapest seller that can fill the amount and the duration, and the TRX comes off a balance you topped up earlier, the same way a person would deposit TRX before renting.

The key belongs to the cabinet account: an email and a code, no KYC. It is shown once, when you create it. You can pin it to the public IPv4 addresses of the machines that call, so a leaked key is not a key from the whole internet.

What you actually call

Send X-API-KEY. Numbers in the JSON are numbers. A numeric string is rejected, which is an easy bug to ship and an annoying one to find.

The energy call is a dry run of sending 0.000001 USDT from your payout wallet to the person you are paying. The sender has to be an active address that holds at least that much USDT. You get back the energy already on the sender, the energy this transfer would use, and four bandwidth fields, so the same call tells you whether to rent bandwidth too. The energy figure is the real consumption, penalty included. 64,285 if the recipient already has a USDT balance, 130,285 if they do not. If the simulation reverts, you do not get a small fake number to order against. No USDT on the sender is one error. A transfer that reverts for some other reason is another. The call does not buy anything. If available_bandwidth is below required_bandwidth, rent the gap with POST /api/v1/bandwidth before you sign. A USDT transfer without a note needs 345 points. The free pool and the delegated pool are not added together, so the delegated pool has to cover the transfer on its own. Bandwidth uses the same key and the same TRX balance, and its orders are separate. How to rent bandwidth. What the dry run is and is not matters, because a reverted estimate is smaller than a real transfer and would under-buy the energy.

You cannot order 64,285. The smallest order is 65,000 and the largest is 4,000,000. The order with the usual 715 of slack is 65,000 or 131,000. If the sender already has enough energy, skip the order. If the gap is under 65,000, you still order 65,000. The minimum is the minimum.

A quote tells you the floor and does not charge. The order has no price field. It charges the balance and delegates. For a payout you are about to sign, 15 minutes or one hour matches a single pass through 64,285 or 130,285. An hour refills about 2,678 energy on a 64,285 limit, which is not a second payout. If the target address has never been activated, the order creates it first unless you forbid that. The balance has to cover energy and activation together. How that price is chosen is the same rule the website uses.

Give the order an idempotency key between 8 and 128 characters. The same key and the same body return the original result, which is what you want when a timeout makes you unsure whether the first call landed. The same key with a different body is a conflict, on purpose. The order is filled when a confirmed energy delegation to that address covers at least 98% of what you bought.

If you set a callback, you get order.filled or order.cancelled as a POST. The signature header is HMAC-SHA256 of the raw body, hex, with your secret. Answer 2xx and it stops. Otherwise it tries five times, waiting 60 seconds, then 5 minutes, then 15 minutes, then an hour. The fifth failure is the last. The account can make 100 calls in a UTC minute and 5,000 in a UTC hour, across every method except the health check, which does not use the key. Every field is on the API reference. The reference is the spec. This is the order of operations.