API аренды энергии TRON: схема интеграции

Коротко: API аренды энергии TRON нужен, когда вы отправляете USDT от имени клиентов и не можете заказывать энергию руками. Интеграция — два запроса: котировка GET /pricing/quote и заказ POST /orders на адрес клиента. На 1 000 выплат в месяц без энергии сеть сожгла бы около 6 430–13 030 TRX, поэтому автоматизация окупает себя быстро.

Когда бизнесу нужен именно API, а не бот?

Бот удобен, пока переводы отправляет человек. Когда выплаты делает ваш сервер — обменник рассчитывается с клиентами, мерчант собирает USDT с депозитных адресов, кошелёк даёт пользователям «перевод без TRX», — между решением «отправить» и подписью транзакции нет места ручному шагу. API встраивает заказ энергии в тот же код, который готовит транзакцию.

Посчитаем масштаб. Перевод USDT на адрес, где USDT уже есть, на 21.10.2026 расходует 64 285 энергии; без энергии это 64 285 × 100 SUN = 6 428 500 SUN ≈ 6,43 TRX. На новый адрес — 130 285 энергии, ≈ 13,03 TRX. При 1 000 выплатах в месяц сжигание составит от 6 430 TRX (все получатели «старые») до 13 030 TRX (все новые). Арендованная энергия заменяет это сжигание.

Профиль расхода зависит от модели бизнеса. Мерчант, который собирает USDT с депозитных адресов клиентов на основной кошелёк, почти всегда платит «дешёвый» тариф: основной кошелёк уже держит USDT, значит, каждый сбор — около 65 000 энергии. Обменник, который выплачивает новым клиентам, наоборот, часто попадает на 131 000. Отдельный нюанс сбора — bandwidth: перевод занимает около 345 байт, и 600 бесплатных единиц в сутки на активированном депозитном адресе покрывают один сбор в день. Если сборов с одного адреса больше, закладывайте около 0,35 TRX на каждый сверх лимита или берите bandwidth в аренду вместе с энергией. Стратегии для бизнеса в целом описаны в хабе «Энергия TRON для бизнеса».

Как устроены запросы к API?

Авторизация — ключом в заголовке Authorization: Bearer <api_key>. Ключ и базовый адрес API выпускаются в боте; там же ключ можно перевыпустить или отозвать.

Пример заказа:

POST {API_BASE}/orders
Authorization: Bearer <api_key>
Content-Type: application/json

{
  "receive_address": "T…",
  "energy_amount": 65000,
  "duration_minutes": 60
}

Заказ списывается с баланса аккаунта — того же, что в боте. Сроки аренды — те же, что в боте: 15 минут, 1 час, 1–3 дня. Полное описание и актуальные допустимые значения — в разделе API бота.

Какой объём и срок заказывать на одну выплату?

Главная ошибка интеграций — заказывать «на всякий случай» одинаковые 65 000. Если получатель новый, энергии не хватит, и сеть дожжёт недостающие ~65 000 единиц из TRX — около 6,5 TRX с вашего горячего кошелька. Обратная ошибка — всегда заказывать 131 000: тогда на «старых» получателях вы переплачиваете за половину объёма.

Правильная логика:

1. Перед заказом проверьте, есть ли у получателя USDT: вызов balanceOf к контракту USDT TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t только читает данные и ничего не стоит.
2. Если есть — заказывайте ~65 000, если нет — ~131 000.
3. Ещё точнее — оценить расход конкретного вызова через triggerconstantcontract на узле TRON: так учитывается текущая надбавка динамической энергии. Из 64 285 единиц на 21.10.2026 около 49 635 — именно эта надбавка, и она меняется.
4. Срок выбирайте по реальной задержке между заказом и отправкой. Если сервер подписывает транзакцию через секунды, хватит 15 минут; если выплаты идут пачкой, удобнее час.

Для серии из N выплат с одного горячего кошелька можно попробовать заказать энергию одним заказом на суммарный объём: 10 выплат «старым» получателям — около 643 000 энергии на час вместо десяти отдельных заказов. Доступность такого объёма и цену покажет котировка — начинайте с неё.

Как убедиться, что энергия дошла, прежде чем отправлять USDT?

Ответ на POST /orders содержит статус, по нему видно момент доставки. Но для денег надёжнее проверить и сам блокчейн: метод getaccountresource возвращает лимит и расход энергии адреса. Схема для воркера выплат:

1. Получили задачу на выплату → определили нужный объём.
2. Запросили котировку (опционально, если нужно сверять цену с лимитом).
3. Создали заказ, сохранили идентификатор рядом с задачей выплаты.
4. Ждём, пока доступная энергия адреса не станет ≥ нужной (опрос getaccountresource раз в 2–3 секунды с общим таймаутом).
5. Подписываем и отправляем перевод с разумным fee_limit — это потолок, сколько TRX транзакция может сжечь (подробности — в документации о плате за ресурсы).
6. Если таймаут истёк, а энергии нет — не отправляем, переводим задачу в ручную проверку.

Пункт 6 важен: лучше задержать выплату на минуту, чем молча сжечь 13 TRX на каждой из сотни.

Как обрабатывать ошибки и повторы?

Сетевые сбои неизбежны, и POST /orders — неидемпотентная операция с деньгами. Если ответ не пришёл, заказ мог быть как создан, так и нет. Повтор вслепую рискует оплатить энергию дважды.

Держите в логах пару «задача выплаты — идентификатор заказа» — это ускоряет любой разбор с поддержкой.

Как хранить ключ и следить за балансом?

Ключ API даёт право тратить баланс аккаунта. Поэтому он живёт только на сервере: в переменных окружения или хранилище секретов, не в клиентском коде, мобильном приложении или репозитории. Если ключ мог утечь — отзовите его в боте и выпустите новый, старый перестанет работать.

Баланс аккаунта — это предоплата. Держите на нём запас на сутки-двое выплат и настройте у себя алерт при падении ниже порога. Расчёт порога простой: средний расход энергии в сутки × цена из котировки × запас 1,5–2.

API или смарт-режим: что выбрать?

API даёт полный контроль: вы сами решаете, на какой адрес, сколько и когда. Это нужно, когда отправителей много — депозитные адреса клиентов, пул горячих кошельков. Если же переводы идут с одного-двух адресов, а писать интеграцию незачем, проще смарт-режим: он держит запас энергии на адресе и сам пополняет его после каждого перевода. Механика делегирования, на которой стоят оба варианта, разобрана в статье «Аренда энергии TRON».