API аренды Energy в TRON: надёжный сценарий вывода USDT
Как связать оценку Energy, идемпотентный заказ аренды, проверку делегации и сверку транзакции в сценарии вывода USDT через API TronBid.
API аренды Energy решает одну часть вывода USDT: получение ресурсов для кошелька отправителя. Приложение должно отдельно учитывать оплату аренды, доставку ресурса и перевод токенов. Такое разделение помогает обрабатывать таймауты и повторы без двойной оплаты или повторного вывода.
Оцените ресурсы для фактического отправителя
Начните с кошелька отправителя, получателя, контракта токена и суммы. Оцените нужный вызов контракта USDT и проверьте доступные Energy и Bandwidth отправителя. Баланс, полученный до другого вывода, уже может устареть.
Изучите состав стоимости аренды и используйте калькулятор при планировании интеграции. При параллельных выводах резервируйте доступный ресурс по кошельку: несколько заданий не должны одновременно рассчитывать на одну и ту же Energy.
Получите актуальные пакеты и расчёт
В документации API TronBid описаны действующие методы, поля запросов и ошибки. Публичный каталог пакетов доступен по GET /api/public/quick-rent/skus. Базовый путь API аренды — /api/v2/quick-rent.
Перед POST /quote получите поддерживаемые пакеты и сроки. Используйте доступность и цену из ответа для конкретной попытки: не фиксируйте размеры пакетов в коде и не считайте старый расчёт бессрочным. Храните API-ключ на сервере и передавайте его в заголовке Authorization по документации.
Создайте один заказ на одно намерение аренды
Метод POST /orders принимает idempotency_key. Сохраните постоянный ключ для намерения аренды и повторяйте с ним тот же запрос после таймаута. Документация задаёт длину 8–128 символов. Новый ключ означает новое намерение, а не безопасное продолжение запроса с неизвестным результатом.
Укажите в target_address кошелёк, который будет отправлять USDT. При оплате в сети пропущенное поле по умолчанию равно payer_address. Это не подходит, когда казначейский кошелёк оплачивает ресурс для другого адреса вывода. См. проверку получателя делегации.
Разделяйте оплату и доставку ресурса
Заказ с оплатой в сети начинается с платёжных инструкций. Соблюдайте pay_address, amount_trx и срок действия, а TXID оплаты сохраняйте до повтора любого шага. Сейчас API допускает одно открытое намерение, ожидающее оплату, на одного плательщика: при соответствующем конфликте проверьте существующий заказ.
Оплата с баланса — отдельный режим, который должен быть включён для API-ключа; баланс необходимо пополнить. Не переключайте режим незаметно при повторе. Оплаченный заказ или статус delegating ещё не подтверждают наличие доступного ресурса у отправителя USDT.
Проверьте результат заказа и доступные ресурсы
Опрашивайте GET /orders/:id с ограниченным числом запросов и увеличением интервалов, учитывая ответы об ограничении частоты. Явно обрабатывайте delegated, failed, expired и cancelled. Если ответ содержит effective_energy_amount, сверяйте фактически доставленное количество с ним, а не только с первоначальным запросом.
После успешной доставки обновите ресурсы кошелька перед подписью USDT. Их могли использовать другие задания. Если вызов всё ещё не выполняется, проверьте причины ошибок Energy и FeeLimit.
Отдельно сверяйте сам вывод
Храните внутренний идентификатор операции, ID аренды, TXID оплаты и TXID вывода отдельно. Идемпотентность аренды не делает перевод в блокчейне идемпотентным. После отправки подписанной транзакции проверяйте её результат, прежде чем создавать заменяющий перевод.
Используйте порядок проверки квитанции транзакции. Таймаут означает неизвестный результат до проверки, а не доказанный отказ или автоматический возврат. Начинайте тесты интеграции с имитации ответов API и изолированных аккаунтов: проверьте повторы, задержку доставки, нехватку ресурсов и недоступность провайдеров.