TET TRON ENERGY TERMINAL

Документация API tet.energy

Начинайте с действующего контракта, а не с планов. Все продуктовые эндпоинты используют базовый путь /v1; публичные рыночные данные доступны без учётных данных, а действия покупателя и продавца — через браузерную сессию или API-ключ с нужными scope.

Куда перейти дальше

Базовый путь и модель ответа

Используйте HTTPS на домене tet.energy и добавляйте /v1 к продуктовым маршрутам. Успешный ответ — сам JSON payload, без success-обёртки. Списки возвращают страницу items с next_cursor и has_more там, где есть пагинация. Параметр resource принимает актуальные значения energy или bandwidth.

Браузерная сессия и API-ключ — разные учётные данные

Браузер подписывает точное сообщение из /v1/auth/nonce и отправляет его в /v1/auth/verify; ответ создаёт сессию и возвращает CSRF-значение для мутаций с сессионной авторизацией. Автоматизация передаёт API-ключ со scope в Authorization: Bearer <api-key>; scope read, buy и sell ограничивают доступ, а мутациям по API-ключу браузерный CSRF не нужен. Создавайте, просматривайте и отзывайте ключи только из авторизованной браузерной сессии. Никогда не помещайте ключ в query string, исходный код или лог.

Повторяйте денежные операции без дубликатов

POST /v1/orders, /v1/orders/batch, /v1/multisig/sessions и /v1/seller/reinvestment/sessions требуют непустой Idempotency-Key длиной до 128 символов; продление аренды также принимает такой ключ. Создавайте один ключ на задуманное действие и повторяйте его только с идентичным запросом. Replay возвращает существующий ресурс, а изменённое тело с тем же ключом даёт conflict.

Единая обёртка ошибок

Любая HTTP-ошибка возвращается внутри error с укрупнённым code и безопасным message. request_id можно передать поддержке для сопоставления с серверным журналом. details появляется только при ошибке валидации 422 и называет поля, не повторяя отправленные значения. Успешные ответы эту обёртку не используют.

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

Текущая HTTP-поверхность

Публичные данные рынка

Эти чтения не требуют учётных данных. Они отдают текущую цену, глубину, исполняемые публичные заказы, завершённые сделки, свечи, статистику рынка и публичный каталог продавцов.

  • 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}

Приватные маршруты покупателя

Чтение заказов, активных аренд и баланса требует read, изменения — buy. Одиночные и атомарные оптовые заказы принимают extension_required, который ограничивает матчинг продавцами с разрешённым продлением, и smart_matching, который предпочитает ранее успешного продавца только внутри одной цены. Продление создаёт один идемпотентный запрос на тот же срок. Multisig-сессии готовят транзакцию и проверяют пользовательские подписи и их вес; сервер никогда не подписывает и не отправляет её.

  • 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

Приватные маршруты продавца

Состояние пула, делегации и заработок доступны авторизованному продавцу. smart_reuse влияет на приоритет повторного продавца только внутри одной цены, auto_extend управляет запрошенным покупателем продлением на тот же срок, а earnings возвращает next_payout_at, когда текущая политика делает обязательство выплачиваемым. Reinvestment готовит unsigned FreezeBalanceV2 из одной завершённой выплаты; продавец подписывает и отправляет её в TronLink, сервер — никогда.

  • 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}

Чего нет в текущем API

В текущем клиентском контракте нет webhook, маршрута вывода средств и клиентского администрирования. Реферальные выплаты исполняет операторский worker, а не клиентский эндпоинт. Отдельного маршрута адреса пополнения нет: авторизованный GET /v1/balance возвращает nullable-поле deposit_address, когда сервис настроен и готов. Health- и операторские административные маршруты не входят в эту клиентскую поверхность.