Mixed hot & cold recipients
A single payroll or affiliate run hits both addresses that already hold USDT and brand-new ones — quote each recipient at the right pack size.
API docs live on docs.eopen.io
Use the external docs as the source of truth for endpoints, fields, auth, idempotency keys, and webhook callbacks. Open API docs →
EOPEN
TRON Energy API for Payout & Disbursement Systems
Provision Energy ahead of large outbound USDT batches — payroll runs, merchant settlements, and affiliate payouts — with idempotent orders, predictable per-payout cost, and tx-hash plus webhook reconciliation.
Plan a payout batchEnergy for Large Outbound USDT Batches
Built for mixed hot/cold recipients at batch scale
EOPEN lets payout and disbursement platforms pre-stage Energy for an entire run, so a batch of thousands of USDT transfers settles inside its P99 window without a single wallet starving on fees.
Batch
Thousands per run
Idempotent
Safe retries
P99
Settlement latency
Webhook
Reconciliation
Payout System Fit
Predictable per-payout cost
Lock the on-chain fee per recipient before the run so finance can model batch cost to the cent instead of padding against burn spikes.
Idempotent & retry-safe
Pair each Energy order with a payout ID so a retried or partially failed batch never double-delegates or double-pays.
01
A batch is only as fast as its slowest payout
Payout platforms are judged on P99 settlement latency, not the median. If one wallet runs dry on Energy mid-batch, that payout retries, the run skews, and recipients open tickets. Pre-staging Energy for the whole batch removes the fee variable from your latency budget.
- Provision Energy for the full recipient list before the run starts.
- Keep each delegation verifiable on TRON for reconciliation.
- Use webhook callbacks to mark each payout settled or failed.
02
Idempotency and retries on failed payouts
In a disbursement system the dangerous failure is the ambiguous one: did the transfer land or not? EOPEN orders carry your payout/batch IDs so a retry reuses the same intent, and the tx hash gives finance a single source of truth when reconciling against your ledger.
- Attach a payout ID / idempotency key to every Energy order.
- Separate API keys per batch, region, or business line.
- Reconcile by tx hash and webhook, not by guesswork.
03
Worked cost example for a payout batch
Take a 10,000-recipient payout run that is 70% hot (recipients already hold USDT, ~64,285 Energy each) and 30% cold (new / zero-balance, ~130,285 Energy each). Burning straight TRX, that is roughly 6.4 TRX × 7,000 plus 13 TRX × 3,000 ≈ 83,800 TRX of fees in one run. Renting the matching 65,000- and 131,000-Energy packs lands those near 1.5 TRX and 3.5 TRX each ≈ 21,000 TRX — savings of up to 80% — locked in before the batch ships.
- Hot recipient (already holds USDT): 65,000 Energy (≈ 6.4 → 1.5 TRX per payout).
- Cold recipient (new / zero-balance): 131,000 Energy (≈ 13 → 3.5 TRX per payout).
- Stage a 500,000-Energy bulk pack to cover the whole run, delegated just before it starts.
Next steps
Size a bulk pack to your next run, key every order to a payout ID, and keep the on-chain fee out of your P99 settlement budget.
Core API flow
- 1Authenticate the payout system with its API key and tag the call with a batch ID.
- 2Quote the run by recipient mix — 65,000 Energy for hot recipients, 131,000 for cold, or one 500,000-Energy bulk pack for the whole batch.
- 3Submit idempotent orders (payout ID as the key) and delegate Energy to your disbursement wallets before the run starts.
- 4Ship the batch inside its P99 window, then reconcile each payout by tx hash and webhook callback.
Payout FAQ
How do I handle a batch with both hot and cold recipients?
Quote each recipient by address type — a ~65K pack for recipients that already hold USDT and a ~131K pack for new, zero-balance ones — or provision one bulk pack sized to the whole run.
Are Energy orders safe to retry on a failed payout?
Yes. Attach your payout or batch ID as an idempotency key so a retry reuses the same intent. Use the tx hash and webhook callback to confirm settlement before re-sending.
How do we reconcile a run with finance?
Every Energy delegation and transfer is verifiable on TRON. Store the tx hash with each payout record and let webhook callbacks drive settled/failed state in your ledger.
Migration & verifiability
Why do I see different field names in old docs vs new docs?
Field naming, idempotency keys, and webhook callback details are maintained on docs.eopen.io. This page keeps only the payout scenario overview.