TET TRON ENERGY TERMINAL

tet.energy API documentation

Start with the current contract, not a roadmap. Every product endpoint uses the /v1 base path; public market data needs no credential, while buyer and seller actions use either a signed-in browser session or a scoped API key.

Choose the next step

Base path and response model

Use HTTPS on the tet.energy origin and append /v1 to product routes. A successful response is the JSON payload itself, with no success wrapper. List routes return an items page with next_cursor and has_more when paging applies. Query values such as resource use the current energy or bandwidth enum.

Browser sessions and API keys are different credentials

A browser signs the exact message returned by /v1/auth/nonce and submits it to /v1/auth/verify; the response establishes a session and supplies the CSRF value required on session-backed mutations. Automation sends a scoped API key as Authorization: Bearer <api-key>; read, buy and sell scopes limit what it can call, and API-key mutations do not use browser CSRF. Create, list and revoke keys only from a signed-in browser session. Never put a key in a query string, source file or log.

Retry money-path mutations without duplicating them

POST /v1/orders, /v1/orders/batch, /v1/multisig/sessions and /v1/seller/reinvestment/sessions require a non-blank Idempotency-Key up to 128 characters; rental extension also accepts one. Generate one key per intended action and reuse it only with the identical request. Replays return the existing resource, while a changed body under the same key is a conflict.

One error envelope

Every HTTP failure is returned under error with a coarse code and safe message. request_id can be supplied to support for server-side correlation. details appears only for 422 validation failures and names fields without echoing submitted values. Successful responses do not use this envelope.

{
  "error": {
    "code": "invalid_request",
    "message": "...",
    "request_id": "...",
    "details": [{ "field": "body.amount", "reason": "..." }]
  }
}

Current HTTP surface

Public market data

These reads require no credential. They expose current price, depth, fillable public orders, settled trades, candles, market statistics and the public seller directory.

  • GET /v1/price
  • GET /v1/market/depth
  • GET /v1/market/orders
  • GET /v1/market/trades
  • GET /v1/market/ohlcv
  • GET /v1/market/stats
  • GET /v1/sellers
  • GET /v1/sellers/{address}

Private buyer routes

Order, active-rental and balance reads require read; mutations require buy. Single and atomic batch orders accept extension_required, which restricts matching to sellers that allow renewal, and smart_matching, which prefers a previously successful seller only inside the same price level. Rental extension creates one idempotent same-term request. Multisig sessions prepare a transaction and verify user signatures and weight; the server never signs or broadcasts it.

  • GET /v1/orders
  • POST /v1/orders
  • POST /v1/orders/batch
  • GET /v1/orders/{order_id}
  • PATCH /v1/orders/{order_id}
  • DELETE /v1/orders/{order_id}
  • GET /v1/rentals
  • GET /v1/rentals/incoming
  • POST /v1/rentals/{rental_id}/extend
  • POST /v1/multisig/sessions
  • POST /v1/multisig/sessions/{session_id}/signatures
  • GET /v1/multisig/sessions/{session_id}
  • GET /v1/balance

Private seller routes

Pool state, delegations and earnings require an authenticated seller. smart_reuse affects reuse priority only within an equal price, auto_extend controls buyer-requested same-term renewal, and earnings reports next_payout_at when the current policy makes a liability payable. Reinvestment prepares an unsigned FreezeBalanceV2 from one completed payout; the seller signs and broadcasts it in TronLink, never the server.

  • GET /v1/seller/pool
  • PATCH /v1/seller/pool
  • POST /v1/seller/pool/sync
  • GET /v1/seller/delegations
  • GET /v1/seller/earnings
  • POST /v1/seller/reinvestment/sessions
  • POST /v1/seller/reinvestment/sessions/{session_id}/confirmation
  • GET /v1/seller/reinvestment/sessions/{session_id}

What is not part of the current API

The current customer contract has no webhook, withdrawal route or customer administration API. Referral payouts run in an operator worker rather than a customer endpoint. There is no standalone deposit-address route: authenticated GET /v1/balance returns nullable deposit_address when the deposit service is configured and ready. Health and operator administrator routes are outside this customer surface.