TRONTEO FOR BUSINESSYour product. Our energy.
One API for Energy and Bandwidth. Get a quote, confirm your order and track the result.
API base URL: https://api.tronteo.com/api/v1
1. Get a quote
POST https://api.tronteo.com/api/v1/quotes
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{"receiver":"YOUR_TRON_ADDRESS","resource":"ENERGY","quantity":65000,"duration":3600,"currency":"TRX"}
duration is in seconds: Energy — 3600; Bandwidth — 3600, 86400 or 259200. Defaults to 3600. Quotes expire in 60 seconds. total is a decimal string in TRX. Orders use the TRX balance only. The recipient must be active on TRON.
2. Confirm your rental
POST https://api.tronteo.com/api/v1/orders
Authorization: Bearer YOUR_API_KEY
Idempotency-Key: unique-order-001
Content-Type: application/json
{"quote_id":"QUOTE_ID","max_amount":5000000}
max_amount is in SUN: 1 TRX = 1,000,000 SUN. Retrying with the same key and unchanged quote_id and max_amount returns the original order.
3. Track the result
GET https://api.tronteo.com/api/v1/orders/ORDER_ID
Authorization: Bearer YOUR_API_KEY
Delegation is complete only when status=confirmed. A review status keeps funds reserved for reconciliation; do not create a replacement order with a new key.
Telegram bots and applications
The API supports application and bot integrations, including resource delivery to end-customer addresses. There is no separate technical reseller role or activation step. The API key and service balance belong to your account; keep the key on your backend. Standard acceptable-use terms apply to you and recipient addresses. Separate commercial guarantees, SLAs or custom resale terms require agreement with support.
Terms of Service4. Free sandbox
Use the separate base URL with your regular API key. Sandbox provides 1000 virtual TRX per account. It does not use real funds, production orders, suppliers or the blockchain. Fixed example prices are not rental offers.
https://api.tronteo.com/api/v1/sandbox
POST /quotes
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{"receiver":"YOUR_TRON_ADDRESS","resource":"ENERGY","quantity":65000,"duration":3600,"scenario":"confirmed"}
POST /orders
Idempotency-Key: telegram-test-001
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{"quote_id":"SANDBOX_QUOTE_ID","max_amount":2000000}
GET /orders/ORDER_ID
GET /orders?idempotency_key=telegram-test-001
GET /balance
Methods mirror production rentals. scenario accepts confirmed, failed or review. Creation returns reserved; the first detail request advances to pending, the second to the selected outcome. Listing does not advance state. Quotes and orders always have simulated=true; txid is empty, txids=[], and delegation_verified=false even for a simulated confirmation.
The initial virtual balance is not replenished or automatically reset. Capacity is 1000 orders and 1000 unexpired quotes per account. failed releases the reservation; review retains it. Use another sandbox order for further testing; do not switch to production.
Response formats
Examples below are synthetic. total, available and reserved are TRX strings with six fractional digits. max_amount and *_sun fields are integer SUN: 1 TRX = 1,000,000 SUN. quantity is an integer resource amount; duration is seconds. created, updated, expires and resets_at are UTC Unix timestamps in seconds. Avoid floating-point money calculations.
POST /quotes → 200
{
"id": "quote_example",
"receiver": "YOUR_TRON_ADDRESS",
"resource": "ENERGY",
"quantity": 65000,
"currency": "TRX",
"total": "2.000000",
"expires": 1793635260,
"duration": 3600,
"simulated": false
}
POST /orders · GET /orders/ORDER_ID → 200
{
"id": "order_example",
"receiver": "YOUR_TRON_ADDRESS",
"resource": "ENERGY",
"quantity": 65000,
"duration": 3600,
"currency": "TRX",
"total": "2.000000",
"status": "reserved",
"txid": "",
"txids": [],
"delegation_verified": false,
"created": 1793635200,
"updated": 1793635200,
"channel": "api",
"bundle_id": null,
"idempotency_key": "telegram-order-001",
"error_code": null,
"simulated": false
}
idempotency_key is included in every order response. error_code is null or a safe diagnostic code; supplier internals are not exposed. txid is the first delegation hash for compatibility; txids contains all recorded hashes. Historical orders may have only the first hash.
GET /orders?offset=0&limit=50 → 200
{
"orders": [
{
"id": "order_example",
"receiver": "YOUR_TRON_ADDRESS",
"resource": "ENERGY",
"quantity": 65000,
"duration": 3600,
"currency": "TRX",
"total": "2.000000",
"status": "reserved",
"txid": "",
"txids": [],
"delegation_verified": false,
"created": 1793635200,
"updated": 1793635200,
"channel": "api",
"bundle_id": null,
"idempotency_key": "telegram-order-001",
"error_code": null,
"simulated": false
}
]
}
Newest first, then id; offset ≥ 0, limit 1–100 (default 50). idempotency_key filters exact matches within your account; no match returns {"orders":[]}.
GET /balance → 200
[
{
"asset": "TRX",
"available": "98.000000",
"reserved": "2.000000"
}
]
available is spendable; reserved is held by unresolved orders. Confirmation consumes the reservation; failed returns the full order total to available; review retains it pending reconciliation. These are service credits, not an on-chain wallet balance.
Retries, timeouts and key retention
Idempotency-Key: 1–100 characters, one unique key per business operation. Uniqueness is account-wide, across API keys and channels. No automatic key TTL is applied: keys remain with the order, without a promise of permanent retention. Keep your own key and order ID.
The same quote_id and max_amount return the original order, including after quote expiry. Changed quote_id or max_amount (including null/omitted) returns 409 idempotency_conflict. Legacy orders without a parameter snapshot check quote_id and the new amount ceiling. Different keys can create distinct paid orders even against the same quote.
GET /orders?idempotency_key=YOUR_ORIGINAL_KEY
After a timeout, first look up the original key. If absent, retry the original request with its original key and parameters; 409 quote_expired requires a new quote. Never replace an uncertain order using a new key.
States and delegation verification
reserved- Funds reserved; awaiting processing.
submitting- Submitting; the creation outcome may still be uncertain.
pending- Accepted; awaiting delegation confirmation.
review- Manual reconciliation required; this is neither a failure nor a refund.
confirmed- Final success; reservation consumed.
failed- Final failure; the full reservation is released. The same key cannot create a replacement.
refund_due- Manual refund for accountless instant rentals; ordinary API orders use failed.
In production compare receiver, resource, quantity, duration, status, delegation_verified and txids. Confirmation requires successful solidified on-chain delegation of the specified resource to the receiver. quantity is the requested resource amount, not the TRON contract stake balance: stake balance cannot be directly compared to Energy. Several delegations may fulfil one order.
Polling every 5–10 seconds is sufficient. For review, do not repurchase: send support the order ID, original key and any txids. Funds remain reserved pending reconciliation. There is no public force-confirm/refund endpoint or guaranteed reconciliation deadline.
Limits and errors
GET /limits
{
"daily_limit_sun": 100000000,
"used_sun": 2000000,
"remaining_sun": 98000000,
"resets_at": 1793664000,
"rate_limit_per_minute": 300,
"scope": "account; all API keys share usage; UTC calendar day"
}
Daily usage sums the retail total of account API orders created in the UTC calendar day, excluding failed. Confirmed, active and review orders count; the current key’s limit applies. Reset is 00:00 UTC. There are 300 authenticated requests per fixed minute per account, shared by all keys and sandbox; rolled-back requests may not consume quota. On 429 respect Retry-After and use jittered backoff.
{
"detail": "Idempotency key was used for another request",
"code": "idempotency_conflict"
}
{
"detail": "Проверьте введённые данные / Please check your input",
"code": "invalid_request",
"fields": [
"quantity"
]
}
401: authentication; 403: access/daily budget; 404: object not found in your account; 409: key conflict, expired quote, price ceiling or balance; 422: input; 429: rate limit; 500/503: service error. Use code programmatically; detail is human-readable and may be bilingual. A create error/timeout does not prove that no order exists: reconcile the original key first.
Key management
Separate keys, revocation and a daily API limit in TRX. Keys are available after email verification.
SEAMLESS · PILOTResources before broadcast
We are preparing automatic resource allocation before a transaction is sent. The feature is in closed testing; access terms are agreed individually.