API-ключи биржи: как выдать доступ и не потерять деньги

API-ключ биржи даёт приложению доступ к отдельным функциям твоего аккаунта без передачи логина, пароля и кода 2FA. Подключать его можно безопасно, если выдать ровно нужные права, запретить вывод средств, привязать ключ к IP и создать отдельную пару ключей под каждую задачу. Ключ с правом вывода в обычной торговой интеграции не нужен вообще: по смыслу это ключ от депозита.

Фраза «как подключить API биржи» часто звучит как техническая мелочь: скопировал API Key, вставил Secret, нажал Connect. Но именно в этот момент ты определяешь, что чужой сервис, бот или твой скрипт сможет сделать с деньгами. Ошибка здесь дороже, чем неверно поставленный стоп-лосс из разбора риск-менеджмента.

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

Что такое API-ключ биржи и что он реально даёт?

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

Публичные котировки, стакан и часть данных по инструментам часто доступны без авторизации. В документации Bitunix публичные запросы прямо отделены от приватных: для последних требуется API Key и подписанный запрос. Это полезная граница. Если сервису нужны только цены BTC или свечи, ему вообще не надо выдавать доступ к твоему аккаунту.

После авторизации набор действий зависит от разрешений. Названия различаются: Read, View, Read-only, Trade, Spot trading, Futures trading, Withdraw. Смысл почти одинаковый:

Разрешение	Что обычно может сервис	Когда включать	Риск при утечке
Read / Read-only	Смотреть баланс, позиции, историю ордеров и сделок	Аналитика, налоговый отчёт, мониторинг	Раскрытие данных об аккаунте и стратегии
Trade	Выставлять и отменять заявки, иногда менять торговые параметры	Проверенный бот или терминал, который исполняет ордера	Убыточные сделки, комиссии, открытие позиции с плечом
Transfer	Переводить средства между внутренними счетами или субсчетами	Только если функция технически необходима и понятна	Перемещение активов внутри аккаунта
Withdraw	Отправлять активы с биржи на внешний адрес	Практически никогда для торговой интеграции	Прямая потеря активов

На OKX документация разделяет доступ на Read, Trade и Withdraw. Read позволяет получать сведения об аккаунте и истории, Trade позволяет создавать и отменять ордера, Withdraw позволяет выводить средства через API. Это не уровни «удобства», а разные уровни контроля над деньгами.

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

Почему право Withdraw равно ключу от депозита?

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

Есть нюанс: у биржи могут быть дополнительные барьеры, например белый список адресов, внутренние проверки риска или требование заранее добавить адрес. Это хорошо, но не повод включать Withdraw «на всякий случай». Контроль нужно ставить слоями, а не рассчитывать на один последний барьер.

Представь два ключа.

Первый имеет Read + Trade, привязан к IP сервера и работает только для фьючерсного бота. При утечке атакующий всё ещё может пытаться торговать от твоего имени, если доберётся до разрешённого сервера или его сети. Ущерб возможен, особенно при кредитном плече, о котором подробнее есть в материале «Что такое кредитное плечо на бирже». Но он не должен иметь прямой команды вывести активы на свой кошелёк.

Второй имеет Read + Trade + Withdraw без IP-привязки. Это уже не «ключ для бота с дополнительной галочкой». Это секрет, который при компрометации способен дать атакующему возможность распоряжаться средствами значительно шире.

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

Какие права выбрать для своей задачи?

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

Для аналитики: «сервис должен только показать баланс, позиции и сделки». Нужен Read-only. Такой сценарий подходит для личной таблицы, дашборда, трекера портфеля или анализа торгового дневника. О том, какие данные полезно фиксировать, читай в гайде по дневнику криптотрейдера.

Для уведомлений: «скрипт должен только читать цену и присылать сигнал». Иногда ключ не нужен совсем, если используются публичные рыночные данные. Если сервису необходимы твои открытые ордера или позиции, нужен только Read.

Для полуавтоматической торговли: «терминал должен выставлять и отменять заявки». Нужны Read + Trade. Read часто требуется сервису, чтобы видеть доступный баланс, текущую позицию и статус ордера. Withdraw, как правило, не нужен.

Для автоматического бота: «бот должен читать позиции и управлять ордерами на выбранном рынке». Нужны Read + Trade только для тех рынков, если биржа позволяет раздельные разрешения. До выдачи Trade убедись, что понимаешь риск стратегии. Сетка, усреднение и торговля без стопа не превращаются в безопасные только потому, что их исполняет код. Полезно сначала изучить, как работает сеточный бот, и протестировать правила без реального депозита.

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

Как подключить API биржи безопасно: порядок действий

Безопасное подключение начинается не с генерации ключа, а с проверки сервиса и подготовки аккаунта. Не вводи API Secret в форму по ссылке из личного сообщения, рекламного баннера или сообщения «службы поддержки». Открой домен сервиса самостоятельно и проверь, что понимаешь, кто будет получать доступ.

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

2. Определи задачу и выпиши минимальные права. Например: «таблица учитывает PnL, ей нужен только Read». Или: «бот создаёт заявки на фьючерсах, ему нужны Read и Trade, без Withdraw».

3. Создай новый ключ именно под эту задачу. В названии оставь назначение, платформу и дату: portfolio-read-2026-10, bot-futures-trade-2026-10. Через несколько месяцев это спасает от гадания, какой из семи безымянных ключей можно удалить.

4. Если сервис работает с фиксированного сервера, добавь его IP в allowlist до подключения. Не указывай диапазон «на всякий случай», если достаточно одного адреса. Проверь IP у поставщика сервиса в его официальной документации или у своего администратора.

5. Не включай Withdraw. Также выключи transfer, управление субаккаунтами и другие разрешения, если задача их не требует.

6. Скопируй API Key, Secret и, если требуется, passphrase только в доверенное поле выбранного сервиса или в защищённое хранилище. Не отправляй их в Telegram, почту, комментарий к задаче, облачный документ или скриншот.

7. Подключи ключ и проведи безопасную проверку. Для Read-key проверь отображение баланса и истории. Для Trade-key сначала выставь и отмени небольшую лимитную заявку на ликвидной паре либо используй демо-среду, если она доступна у конкретной биржи.

8. Вернись в раздел API Management и убедись, что у созданного ключа именно ожидаемые права, IP и понятное имя. Затем запиши дату следующего аудита в календарь.

На Bybit создание и удаление API-ключей описаны в справочном центре, а сама генерация ключа подтверждается 2FA. У OKX в FAQ указано, что при создании задаются имя, IP allowlist, разрешения и passphrase. Меню может выглядеть иначе, но поля, которые тебе нужны, будут примерно такими.

Зачем создавать отдельный ключ под каждый сервис?

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

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

Разделение меняет картину:

Интеграция	Имя ключа	Нужные права	IP-привязка	Что отключить при проблеме
Таблица или аналитика	analytics-read	Read	По возможности	Только чтение
Торговый терминал	terminal-trade	Read + Trade	IP терминала, если статичен	Торговый терминал
Бот на VPS	bot-vps-trade	Read + Trade	Внешний IP VPS	Только бота
Тест нового сервиса	test-read-2026-10	Read	По возможности	Весь тестовый доступ

Это принцип минимальных привилегий: процесс получает только доступ, без которого не выполнит свою работу. AWS в рекомендациях по управлению доступом формулирует тот же подход: начинать с минимального набора разрешений и добавлять права лишь по необходимости.

Отдельный ключ ещё и дисциплинирует. Когда при создании приходится назвать интеграцию, проще заметить странность: «Зачем этому трекеру портфеля право на фьючерсную торговлю?» Обычно ответ будет: незачем.

Как работает IP-привязка и когда она не спасёт?

IP-привязка говорит бирже принимать API-запросы только с указанных сетевых адресов. Если API Key и Secret утекут в публичный репозиторий, человек с другого IP не должен суметь использовать их. Это сильное ограничение, которое стоит включать везде, где известен постоянный адрес сервера.

У Bitunix документация сообщает ошибку, когда текущий IP отсутствует в белом списке ключа. У BingX в настройках API также указана возможность привязать до 20 IP-адресов для одного ключа. У OKX документация говорит о лимите до 20 адресов на ключ. Число не должно становиться целью: если нужен один IP, добавляй один.

IP-привязка не делает ключ бессмертно безопасным. Она не поможет, если:

• атакующий получил доступ к твоему VPS, где уже разрешён этот IP;
• ты добавил слишком широкую подсеть или устаревший адрес;
• вредоносный код работает на том же сервере, что и бот;
• сервис использует меняющиеся IP, а ты из-за этого отключил ограничение;
• ключ с Withdraw уже имеет другие пути обхода защиты внутри разрешённой инфраструктуры.

Если торговый сервис не публикует фиксированные IP, не угадывай адреса и не переписывай случайный IP из чата. Либо используй только Read, либо оцени, готов ли ты принять риск Trade-доступа без allowlist. В таком случае особенно полезен отдельный ключ с ограниченным назначением и без вывода.

Где хранить API Key и Secret?

API Key можно считать идентификатором, а Secret и passphrase нужно хранить как пароль от денег. Секретная часть часто показывается один раз. Если потерял её, нормальный путь не «восстановить», а отозвать ключ и создать новый.

Для одного человека без разработки подойдёт менеджер паролей с сильным мастер-паролем и 2FA. Храни там секретную часть как отдельную запись, а не в заметке с названием «ключи». Не клади её в облачный документ, который открыт по ссылке, и не прикрепляй к карточке задачи.

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

Плохие места для API Secret:

• скриншот экрана при настройке;
• чат с поддержкой или «менеджером»;
• Telegram Saved Messages;
• публичный или приватный репозиторий без контроля доступа;
• заметка в браузере, доступная на чужом устройстве;
• исходный код, который ты отправляешь нейросети для отладки;
• видеоэкран при демонстрации бота.

Последний пункт многие недооценивают. Даже если секрет показан на секунду, запись можно поставить на паузу. Перед записью экрана закрой раздел API Management, терминал с переменными окружения и менеджер паролей.

Что может потерять трейдер: учебный расчёт

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

Допущения:

1. На деривативном счёте лежит 1 000 USDT.
2. Ключ разрешает фьючерсную торговлю и не имеет IP-привязки.
3. Через него открыта позиция объёмом 10 000 USDT, то есть условное плечо 10x к капиталу.
4. Цена двигается против позиции на 5%.
5. Комиссии, funding и проскальзывание не учитываем.

Расчёт: 10 000 USDT × 5% = 500 USDT.

При этих допущениях убыток составит 500 USDT, то есть половину счёта. Это не прогноз и не утверждение о ликвидационной цене. На реальном фьючерсном рынке результат зависит от маржи, режима позиции, поддерживающей маржи, комиссии и движения цены. Но арифметика объясняет, почему доступ Trade тоже не стоит выдавать «первому удобному боту».

Отдельно проверь настройки риска до API-подключения: какие рынки доступны, какое плечо выставлено, разрешены ли условные ордера. В материале о ликвидации в крипте разобрано, почему небольшое движение цены при высоком плече может оказаться критичным.

Read-only не устраняет риск полностью. Если утекут данные о балансе, позициях и истории, мошенники получают материал для точного социального инженеринга: могут написать от имени «поддержки», назвать твою позицию и попросить «подтвердить защиту аккаунта». Но Read-key хотя бы не должен напрямую ставить ордера и выводить деньги.

Какие ошибки с API-ключами встречаются чаще всего?

Первая ошибка: создать ключ с максимальными правами, чтобы «ничего не сломалось». В нормальной настройке сначала не хватает прав, интеграция показывает конкретную ошибку, и ты добавляешь только необходимое разрешение. Это лучше, чем широкая выдача доступа без понимания.

Вторая: использовать один ключ везде. Когда его приходится отзывать, отключается всё сразу. А если ключ всплывает в логах, непонятно, где именно произошла утечка.

Третья: игнорировать IP-ограничение, хотя бот стоит на VPS со статическим адресом. Часто это делают ради удобства, а потом к IP возвращаются уже после инцидента. Привязку лучше включить до первого запуска.

Четвёртая: отправить Secret человеку, который «поможет подключить». Техподдержка легитимного сервиса не должна просить у тебя секретный ключ в переписке. Если человек просит дать Read + Trade + Withdraw ради консультации, разговор стоит прекратить.

Пятая: хранить ключ в коде и публиковать его. Git хранит историю. Удаление строки из последнего коммита не гарантирует, что секрет исчез из прошлых версий, fork-ов, кешей или сборочных логов.

Шестая: забыть о ключе после теста. В BingX указано, что некоторые не привязанные к IP активные ключи с торговыми разрешениями удаляются после 14 дней бездействия, однако рассчитывать на автоматическое удаление как на стратегию безопасности нельзя. Неиспользуемый ключ надо удалять вручную.

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

Как проверить сервис до выдачи торгового доступа?

Перед Trade-доступом проверь не только сайт, но и модель доступа. Сервис, который просит API Secret, получает возможность подписывать запросы от твоего имени в пределах выданных прав. Поэтому вопрос «выглядит ли сайт нормально» недостаточен.

1. Найди официальный сайт самостоятельно, а не по рекламе или личному сообщению.

2. Прочитай документацию сервиса: какие права он требует, нужны ли IP-адреса, что он делает с ключами, есть ли возможность отключить интеграцию.

3. Сравни заявленные права с задачей. Аналитике не нужен Trade. Торговому боту не нужен Withdraw.

4. Создай сначала ключ Read-only и убедись, что сервис корректно подключается и показывает только ожидаемые данные.

5. Если Trade необходим, создай отдельный ключ. Не повышай права у ключа, который уже использует другой сервис.

6. Проверь, есть ли в кабинете биржи список действий по API или хотя бы история ордеров и переводов. Ты должен понимать, где смотреть последствия.

7. Не доверяй обещаниям «гарантированной доходности» и «нужен вывод, чтобы бот фиксировал прибыль». Прибыль от сделки остаётся на биржевом счёте, и для её фиксации право Withdraw не требуется.

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

Что делать, если ключ уже утёк?

Если API Secret оказался в чате, репозитории, скриншоте, форме сомнительного сайта или на компьютере с вредоносным ПО, считай ключ скомпрометированным. Не жди подтверждения злоупотребления. Удаление или отзыв ключа на бирже должно быть первым действием.

1. Открой кабинет биржи вручную через сохранённую закладку или набранный домен.

2. Найди API Management и удали скомпрометированный ключ. На Bybit удаление ключа выполняется в разделе управления API, а не через мобильное сообщение от «поддержки».

3. Проверь открытые позиции, активные заявки, историю сделок, переводы между счетами и историю выводов. Сделай для себя запись времени обнаружения, чтобы проще сопоставить события.

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

5. Проверь входы в аккаунт, активные сессии, почту и устройство, с которого работал с ключом. При подозрении на компрометацию аккаунта смени пароль и заверши лишние сессии по процедуре биржи.

6. Создай новый ключ только после того, как устранил причину: убрал секрет из репозитория, очистил небезопасное хранилище, настроил IP и сузил права.

7. Если ключ был в Git, удали секрет из истории по инструкции платформы или с помощью специалиста. Но отзыв на бирже не откладывай до чистки истории: старый ключ уже должен стать бесполезным.

Ротация не означает, что нужно менять все ключи по расписанию без причины и ломать рабочие подключения. Это процесс замены ключа: создать новый с теми же минимальными правами, безопасно обновить интеграцию, проверить работу, затем отозвать старый. OWASP рекомендует поддерживать управляемую ротацию секретов, а AWS указывает периодический аудит и ротацию долгоживущих учётных данных как способ сократить срок возможного злоупотребления.

Как проводить регулярный аудит доступа?

Аудит API-ключей раз в месяц или квартал занимает несколько минут и закрывает типовую дыру «ключ для теста остался навсегда». Частоту выбери под число интеграций и торговую активность, но не рассчитывай только на память.

Открой список ключей и по каждому ответь:

• Для какого сервиса создан ключ?
• Кто отвечает за этот сервис?
• Используется ли он сейчас?
• Есть ли у него минимальные права?
• Включён ли Withdraw? Если да, почему это неизбежно?
• Есть ли IP allowlist и актуальны ли адреса?
• Не дублирует ли этот ключ другой?
• Когда он последний раз использовался?
• Можно ли заменить его ключом Read-only?
• Понимаешь ли ты, как отозвать его без остановки остальных интеграций?

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

Смотри и на поведение аккаунта. Неожиданные заявки, изменение настроек, перевод между счетами, незнакомый IP в логах, письмо о создании ключа, которого ты не создавал, требуют немедленной проверки. В торговле привычка смотреть историю сделок полезна не только для статистики: она помогает раньше заметить действие, которого ты не совершал. О том, почему стоп и заранее заданный риск нужны даже при автоматизации, есть материал «Stop-loss: что это и как правильно».

Чем отличаются API-настройки Bybit, OKX, BingX и Bitunix?

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

Биржа	Что подтверждает официальная документация	Практический вывод
Bybit	Создание API-ключа проходит в веб-версии, настройки подтверждаются 2FA; удаление выполняется в API Management	Создавай ключ в своём кабинете, сразу называй по назначению и знай, где его удалить
OKX	Есть права Read, Trade и Withdraw; доступ можно ограничить до 20 IP-адресами	Для аналитики выбирай Read, для исполнения ордеров добавляй Trade, Withdraw не включай
BingX	У ключа можно указать до 20 IP; ключи с выводом должны иметь IP-привязку; подключение ключей с Trade и Withdraw к сторонним платформам отмечено как риск	Не воспринимай обязательную IP-привязку для Withdraw как разрешение его включать
Bitunix	Документация разделяет публичные и приватные запросы; для приватных требуется подпись; есть ошибка для IP вне whitelist	Публичные цены бери без ключа, а ключи с доступом к аккаунту привязывай к IP

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

Если выбираешь площадку для первой торговли, сначала отдели выбор биржи от подключения API. Сравнение функциональности, условий и рисков удобнее делать до автоматизации, а не после того, как ключ уже выдан. Базовые вещи для новичка разобраны в статье «Какую криптобиржу выбрать новичку в России».

Какой чек-лист пройти перед нажатием Create API Key?

Перед созданием ключа пройди этот список. Если один пункт не выполнен, лучше остановиться на нём, а не компенсировать сомнение дополнительными правами.

• Я понимаю, какой сервис подключаю и какую задачу он решает.
• Я открыл официальный сайт сервиса самостоятельно.
• Я создам новый ключ, а не отдам уже работающий ключ другого сервиса.
• Для моей задачи достаточно Read, либо я могу ясно обосновать необходимость Trade.
• Право Withdraw выключено.
• Transfer, субаккаунты и прочие дополнительные права выключены, если не обязательны.
• Я указал понятное имя ключа: сервис, задача, дата.
• Я добавил IP в allowlist, если у сервиса или VPS есть фиксированный адрес.
• Я знаю, где хранить Secret и passphrase.
• Я не буду отправлять секрет в чат, тикет, почту или репозиторий.
• Я знаю, где в кабинете биржи удалить ключ и посмотреть историю операций.
• Я поставил напоминание проверить ключи позднее.

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

Какие ограничения у этой схемы безопасности?

Минимальные права, IP-привязка и отдельные ключи не защищают от рыночного риска. Бот с корректно настроенным Trade-доступом всё равно может потерять деньги по логике стратегии, из-за бага, проскальзывания, ошибки параметров или резкого движения рынка.

Они также не заменяют безопасность устройства. Если компьютер заражён, а злоумышленник получает доступ к браузеру, почте, менеджеру паролей или серверу, одних API-настроек мало. Нужны обновления, уникальные пароли, 2FA, контроль сессий и аккуратность со скачанными файлами.

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

Самая рабочая привычка здесь скучная: не выдавать доступ шире, чем необходимо, и регулярно забирать то, чем больше не пользуешься. В API-безопасности скучные настройки обычно ценнее «умного» бота, который просит ключ от всего аккаунта.

Источники

1. Bybit Help Center, How to Create Your API Key
2. Bybit Help Center, How to Delete Your API Key
3. OKX API FAQ
4. OKX API Guide, permissions and API key security
5. BingX API Management
6. BingX, Security Upgrade for API Key Validity
7. Bitunix API Guide
8. Bitunix Open API, Spot interface documentation
9. OWASP Secrets Management Cheat Sheet
10. AWS Well-Architected, audit and rotate credentials