Model every payout as a state machine
Store the recipient, amount, recommended Energy, quote and your own payout identifier. Validate addresses first, confirm that Energy reached the sending wallet and only then broadcast USDT.
- Validate address format and activation before ordering.
- Use one stable idempotency key per payout.
- Treat a timeout as an unknown result, not a failed order.
Make retries safe
After a network error, fetch the existing order with the same key before creating anything else. Blind retries can reserve resources twice. Separate queued, processing, delivered, broadcast and terminally failed states.
Measure total cost and health
Compare the live Energy quote with expected TRX burn, not an old fixed price. Monitor balance, delivery time and error rate. Log order and transaction IDs, but never private keys or API secrets.
FAQ
Should one API call cover hundreds of wallets?
A controlled queue with a separate idempotent order for each sending wallet is easier to retry and audit.
Does the Energy API need a private key?
No. It only needs a public address; transaction signing should stay inside your secured system.
Sources
Technical facts are checked against official TRON documentation. Resource use can change with network and contract state.
EZ Energy API ↗HTTP idempotency ↗