TRON energy rental API for bots and backend services

Automating TRON energy rental enables Telegram bots, payment processors, and automated payout daemons to execute USDT TRC-20 transfers without manually managing TRX stakes or burning liquid gas. Rather than building custom staking infrastructure or freezing working capital in 14-day network locks, bot developers connect to a programmatic REST API that delegates on-chain energy on demand via Stake 2.0^[3].

The integration follows a structured five-step lifecycle^[1]: fetching an instant estimate, generating HMAC-SHA256 request signatures^[2], securing a 120-second price quote, placing an idempotent order with a custom client_order_id, and confirming delegation via signed webhooks.

The 5-step bot integration lifecycle

Our REST API provides a predictable workflow designed for automated backends:

[Bot / Server]                      [Energy API]                      [TRON Chain]
       |                                   |                                |
       |--- 1. GET /v1/estimate ---------->|                                |
       |<-- Returns total SUN & price -----|                                |
       |                                   |                                |
       |--- 2. POST /v1/quotes ----------->|                                |
       |<-- Returns quote_id (120s lock) --|                                |
       |                                   |                                |
       |--- 3. POST /v1/orders ----------->|                                |
       |<-- 201 Created (ord_...) ---------|--- delegateResource ---------->|
       |                                   |                                |
       |<-- 4. Webhook: order.confirmed ---|<-- Confirmed in block ---------|
       |                                   |                                |
       |--- 5. Broadcast USDT transfer ------------------------------------>|

1. Estimate order cost without credentials

To display instant pricing to bot users or compute transfer fees, query GET /v1/estimate^[1]. This public endpoint requires no API key:

curl -sG https://api.tenergy.me/v1/estimate \
  -d resource=energy -d amount=65000 -d tier=1h \
  -d receiver=TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE

The response returns total_amount_sun, price_sun_per_unit, and detects whether the receiver wallet is activated on chain.

2. Sign requests with HMAC-SHA256

All authenticated endpoints require three HTTP headers^[2]:

• X-API-KEY: Your key identifier (ak_live_... or ak_test_...).
• X-API-TIMESTAMP: ISO 8601 UTC timestamp (5-second tolerance).
• X-API-SIGN: base64(HMAC-SHA256(secret, timestamp + METHOD + path + query + body)).

3. Pin price with a 120-second quote

To shield your bot against price fluctuations during user interaction, call POST /v1/quotes^[1]. A quote pins the total cost for 120 seconds:

{
  "resource": "energy",
  "amount": 65000,
  "tier": "1h",
  "receiver": "TQn9Y2khEsLJW1ChVWFMSMeRDow5KcbLSE"
}

4. Submit an idempotent order

Pass the quote_id and your own client_order_id to POST /v1/orders^[1]. If your server loses connection or times out, safely retry the identical call; our engine recognizes the client order ID and returns the existing order rather than creating a duplicate charge.

{
  "quote_id": "qt_01J9Z5NB2K4R",
  "client_order_id": "bot-order-94812"
}

5. Confirm on-chain delegation

Your bot should wait for confirmation before broadcasting the USDT transfer:

• Webhooks: Register an HTTPS URL in your dashboard. When the delegation is verified on chain, the system delivers an order.confirmed event signed with HMAC-SHA256^[2].
• Polling: As a fallback, poll GET /v1/orders/cid:bot-order-94812 every 1–2 seconds until status transitions to active following on-chain delegateResource^[3].

API endpoints summary

Key architecture practices for bot developers

1. Separate environments: Develop and rehearse bot workflows using our Nile testnet endpoint (https://api-nile.tenergy.me/v1). Testnet keys carry the ak_test_ prefix and are strictly isolated from production accounts.
2. Idempotency keys on every order: Generate a distinct client_order_id for every unique user action. This prevents accidental double billing during network interruptions.
3. Verify partial deliveries: Inspect the partial boolean on order records. If supply runs short, an order can complete partially; the rest is refunded automatically.
4. Broadcast after confirmation: Wait for the order.confirmed webhook or active status before broadcasting the dependent USDT TRC-20 transaction on TRON mainnet.

For technical details, review our full Quickstart guide, Authentication reference, and API documentation.