Как привязать IP-адрес к API-ключу Bybit

Как создать API-ключ на Bybit

Ключи создаются только на сайте: вход с десктопного браузера, раздел Account → API Management, кнопка создания нового ключа. На этом шаге есть две неочевидные преграды. Мобильное приложение ключи не создаёт вовсе, а на свежем аккаунте кнопка может не появляться первые 48 часов — справочный центр Bybit прямо пишет, что создание ключей после регистрации ограничивается в целях риск-контроля.

Дальше форма просит выбрать тип ключа. Системные ключи работают через HMAC: пару «ключ + секрет» выдаёт Bybit, причём секрет показывается один раз — при создании; сохраните его до закрытия страницы. Самогенерируемые ключи работают через RSA: пару создаёте вы, а бирже передаёте только публичную часть — приватный ключ Bybit не хранит. Создание подтверждается 2FA и кодом из письма.

Здесь же стоит зафиксировать окружение. Mainnet, testnet и два демо-окружения используют разные хосты и разные ключи. Ошибка 10003 API key is invalid чаще всего говорит не о самом ключе, а о несовпадении: testnet-ключ отправлен на api.bybit.com или наоборот.

Выбор разрешений ключа

Разрешения выдаются по продуктовым зонам — контрактная торговля, спот, переводы между кошельками, конвертация, earn — поверх базового выбора «только чтение» или «чтение и запись». Рабочее правило — минимальный набор: панели, которая следит за позициями, достаточно чтения; спотовому боту — запись плюс зона Spot и ничего сверх; права на переводы и вывод уместны только на ключах, чья единственная работа — перемещать средства, и у таких ключей белый список должен быть самым строгим.

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

Привязка IP-адреса: что меняет белый список

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

За отсчётом можно следить из самого API. GET /v5/user/query-api возвращает deadlineDay и expiredAt — причём только для ключей без привязки или после смены пароля; у привязанного ключа срока действия просто нет. Когда непривязанный ключ всё же истекает, спотовые запросы возвращают ошибку -2015 Your api key has expired, а деривативные — 33004.

Редактирование списка в 2026 году изменилось. Ченджлог V5 формулирует прямо: с 10 февраля 2026 года добавлять и удалять адреса белого списка через эндпоинт Modify Master API Key больше нельзя. Попытка через API возвращает ошибку 141019 с указанием идти в API Management и нажимать Edit. На практике это значит, что правка списка — ручной шаг в браузере: пайплайны, которые пересоздавали серверы и сами обновляли белые списки ключей, теперь требуют человека. Ещё один аргумент в пользу адреса, который не меняется никогда.

Если запрос приходит с адреса вне списка, Bybit возвращает ошибку 10010 Unmatched IP, please check your API key's bound IP addresses — самый частый отказ на свежепривязанных ключах, и почти всегда дело в несовпадении исходящего адреса, а не в проблеме на стороне биржи.

У Binance тот же 90-дневный отсчёт, но с другим финалом: там ключ без ограничений теряет спотовое торговое разрешение, а не аннулируется целиком. Как работает IP whitelist у API-ключа Binance, мы разбирали отдельно; если боты работают на обеих биржах, списки ведутся независимо и оба указывают на один и тот же статический исходящий адрес.

Какой адрес привязывать — и наш тест доступности

В список вписывается исходящий IP — тот, который видит Bybit, а не тот, что машина показывает локально. За NAT локальный адрес выглядит как 192.168.x.x, биржа же видит роутер; контейнерная платформа может менять исходящий адрес между деплоями; домашний интернет — получить новый адрес от провайдера за ночь. Проверяйте тем же маршрутом, которым ходит бот:

import requests

# Прямой маршрут — исходящий IP самой машины:
print(requests.get("https://api.ipify.org").text)

# Через прокси бота — адрес, который на самом деле увидит Bybit:
proxy = {"https": "http://login:password@PROXY_IP:port"}
print(requests.get("https://api.ipify.org", proxies=proxy).text)

То, что печатает второй вызов, и вписывается в белый список. А поскольку каждая правка списка теперь стоит входа в браузер, стабильный адрес перестал быть удобством и стал требованием конструкции: один статический исходящий IP на ключ, привязанный один раз.

Стабильность — не единственное условие: Bybit должен быть готов отвечать этому адресу вообще. Гайд по интеграции предупреждает, что запросы с IP из США и материкового Китая получают 403 Forbidden, а ряд стран обслуживается с региональных хостов (api.bybit.nl, api.bybit.tr, api.bybit.kz и другие). Помимо географии, известно, что пограничная инфраструктура Bybit отклоняет запросы с диапазонов крупных облачных платформ — 403 приходит до этапа аутентификации, и его легко принять за проблему с ключом.

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

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

Ровно под эту схему собраны наши прокси для криптобирж: выделенные IPv4, статичные весь срок плана, по одному на ключ или бота, в локациях вне ограниченных регионов Bybit, с HTTP, HTTPS, SOCKS4 и SOCKS5 на каждом адресе и доступом по белому списку IP. Привяжите IP прокси в API Management один раз — и ключ не истекает и не спотыкается о 10010.

Подпись запросов: аутентификация V5

Привязка IP не меняет механику подписи — аутентификация V5 едет в четырёх HTTP-заголовках: X-BAPI-API-KEY, X-BAPI-TIMESTAMP (UTC, миллисекунды), X-BAPI-RECV-WINDOW (по умолчанию 5 000 мс) и X-BAPI-SIGN. Подписывается конкатенация timestamp + api_key + recv_window + queryString для GET-запросов; у POST вместо строки запроса — сырое JSON-тело. HMAC-ключи подписывают строку через SHA256 и отправляют hex в нижнем регистре, RSA-ключи — base64.

Полный пример подписи на Python — вызов запрашивает состояние вашего же ключа, так что заодно работает проверкой белого списка:

import hmac, hashlib, time, requests

API_KEY = "YOUR_API_KEY"
API_SECRET = "YOUR_API_SECRET"
RECV_WINDOW = "5000"

def signed_get(path, params):
    ts = str(int(time.time() * 1000))
    query = "&".join(f"{k}={v}" for k, v in params.items())
    payload = ts + API_KEY + RECV_WINDOW + query
    sign = hmac.new(API_SECRET.encode(), payload.encode(),
                    hashlib.sha256).hexdigest()
    return requests.get(
        "https://api.bybit.com" + path,
        params=params,
        headers={
            "X-BAPI-API-KEY": API_KEY,
            "X-BAPI-TIMESTAMP": ts,
            "X-BAPI-RECV-WINDOW": RECV_WINDOW,
            "X-BAPI-SIGN": sign,
        },
    )

# Вернёт разрешения ключа, привязанные IP и — для непривязанных ключей — expiredAt:
print(signed_get("/v5/user/query-api", {}).json())

На этом этапе доминируют две ошибки. 10004 Error sign означает, что подписанная строка не совпала байт в байт с отправленной — строка запроса в подписи должна быть ровно той, что уйдёт по сети, включая порядок параметров. 10002 указывает на часы: timestamp обязан удовлетворять условию server_time − recv_window ≤ timestamp < server_time + 1000, поэтому машина, убежавшая на секунду вперёд биржи, начинает получать отказы. Держите часы под NTP; практика синхронизации с серверным временем Binance применима к Bybit без изменений.