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

Ниже — способ проверить этот перечень и подготовить доступ без публикации секретов. Bybit V5 используется как документированный пример структуры разрешений. Названия полей нельзя автоматически переносить на другую биржу или считать подтверждением совместимости конкретного бота.

Сначала опишите задачу подключения

Составьте короткую карточку: биржа, основной счёт или субсчёт, торговый продукт, среда проверки, программа и машина, на которой она работает. Запишите нужные действия человеческим языком: «читать историю сделок», «получать открытые заявки», «отправлять и отменять заявки». Так легче заметить право, которое не связано с задачей.

• Мониторинг: программа собирает данные, но не должна изменять торговое состояние.

• Исполнение: программа отправляет заявки и проверяет их статус; нужные торговые права определяются продуктом и API.

• Перемещение средств: переводы и вывод — отдельные действия. Если их нет в согласованном процессе, они не должны появляться в доступе «на всякий случай».

Общедоступные рыночные данные могут предоставляться без доступа к частному счёту; это проверяют по документации выбранного метода. Не следует выдавать права на счёт только потому, что программе нужна котировка.

Как читать разрешения на примере Bybit

В описании сведений об API-ключе Bybit V5 поле readOnly отделено от списка permissions: 1 обозначает чтение, 0 — чтение и запись. Среди областей прав указаны ContractTrade с Order и Position, Spot с SpotTrade, а также Wallet с правами перевода и Withdraw; доступность зависит в том числе от основного счёта или субсчёта. Документация также описывает связанные IP и поля срока действия.

Это полезная модель проверки: общий режим ключа и конкретные области доступа нужно читать вместе. Наличие торгового названия в списке не следует трактовать как разрешение на любую операцию. Сопоставьте сведения о ключе с требованиями каждого нужного метода API.

Другой пример — документация Coinbase Exchange, где View, Trade, Transfer и Manage разделены. Одинаковая задача на двух биржах может требовать разных названий прав. Инструкции для одного продукта Coinbase также не заменяют документацию другого.

Почему «без вывода» не означает «без риска»

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

В учебном примере сервис отчётности просит доступ к истории и остаткам, а в предложенной конфигурации присутствует отправка заявок. Несоответствие обнаруживается ещё до подключения: для отчётности торговое действие не заявлено. У торгового робота, наоборот, только чтение может быть недостаточным. Решение определяется задачей, а не правилом «всем всегда один набор галочек».

Проверка подключения по шагам

1. Сверьте счёт и среду. Идентификаторы, продукт и адрес подключения должны относиться к одному согласованному окружению. Demo, testnet и основной счёт могут иметь разные правила и реквизиты.

2. Проверьте чтение. Сопоставьте доступные программе остатки, позиции и историю с ожидаемым счётом. Для этой проверки не требуется совершать новую сделку.

3. Сверьте IP-ограничения. Если они поддерживаются, определите фактический внешний адрес сервера и порядок действий при его изменении. Адрес рабочего ноутбука может отличаться от адреса машины, где запущен бот.

4. Проверьте срок и владельца доступа. Зафиксируйте назначение ключа, ответственное лицо, срок действия и местонахождение защищённой конфигурации, не записывая секрет в общий журнал.

5. Отделите проверку исполнения. Успешное чтение баланса не доказывает возможность отправки нужного ордера. Для разрешённой среды проверки составьте отдельный сценарий заявки, ответа, отмены и сверки состояния.

Различия сред рассмотрены в протоколе сравнения demo и live. А перед проверкой отправки полезно уточнить условия рыночных и лимитных ордеров: разрешение на торговлю и ожидаемый результат исполнения — разные вопросы.

Хранение, замена и отзыв ключа

Секрет ключа, закрытый ключ подписи и дополнительные секретные фразы хранят в предназначенном для этого защищённом месте. Их не включают в скриншоты, видео, письма поддержки, публичные репозитории или обычные журналы. Даже технический ответ API перед передачей следует проверить на идентификаторы и данные доступа.

Для плановой замены заранее определите, кто останавливает автоматические действия, сверяет позиции и заявки, обновляет конфигурацию и подтверждает отзыв старого доступа. Новый ключ не должен незаметно оставить второй работающий экземпляр программы. Отзыв ключа тоже не следует считать автоматической отменой всех биржевых заявок или закрытием позиции: это отдельные состояния, которые необходимо проверить.

Если секрет оказался раскрыт, замазывание уже опубликованного изображения не возвращает ему конфиденциальность. Действуйте через официальные средства отзыва доступа биржи и проверьте историю операций. Для обсуждения интеграции с New Hope можно передать название биржи, продукта и описание задачи; сам ключ и его секрет в форму отправлять не нужно.