API криптобіржі: дозволи, підпис та ліміти запитів

Перше, що ви передаєте API криптобіржі — це не код. Це ключ. Кожен посібник радить тримати його в безпеці; майже жоден не показує, що саме цей ключ може робити на конкретній біржі, де й криється реальний ризик. Цей огляд використовує опубліковану документацію API WEEX як робочий приклад і послідовно відповідає на чотири питання: що таке API, що він може робити, як створюється підписаний запит і що станеться, якщо ключ витече.

Кожен параметр, ліміт запитів і код помилки нижче взято з офіційної документації API WEEX (спотові та ф'ючерсні FAQ, востаннє оновлені 14.04.2026), перевірено в серпні 2026 року. Документація змінюється між версіями — звіряйтеся з актуальними сторінками перед запуском.

Що насправді робить API криптобіржі

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

• Публічні ендпоінти повертають ринкові дані та конфігурацію: свічки, глибину стакану, останні угоди, список торгових пар. Без автентифікації, відкриті для всіх, ліміти запитів за IP.
• Приватні ендпоінти стосуються вашого акаунту: баланси, позиції, розміщення та скасування ордерів. Кожен запит повинен містити підпис, який сервер перевіряє перед виконанням будь-якої дії.

Цей поділ має визначати вашу архітектуру. Ринкові дані можна отримувати будь-де — витік публічного ендпоінту нічим вам не загрожує. Приватні виклики мають виконуватися на хості, вихідну IP-адресу якого ви контролюєте. Багато команд запускають обидва типи в одному процесі, бо це зручно, а потім вразливість залежностей на стороні ринкових даних видає торговий ключ.

WEEX обслуговує спотовий REST через https://api-spot.weex.com, зі спотовими шляхами під /api/v3/ та ф'ючерсними під /capi/v3/. Префікси не є взаємозамінними, і їх змішування є найпоширенішою причиною незрозумілих помилок 404.

Дозволи API-ключа: помилка, яку роблять більшість посібників

Майже кожна стаття про "безпеку API-ключів" на першій сторінці Google припускає три рівні дозволів — читання, торгівля, виведення — і радить вимкнути виведення. Ця порада слушна, але вона приховує важливіше питання: чи пропонує біржа дозвіл на виведення взагалі?

На WEEX — ні. Дозволи, доступні при створенні ключа, є такими, і вони незалежні один від одного:

Це важливіше за будь-які деталі шифрування. Коли ви читаєте про "витік API-ключа, який спустошив акаунт", кошти зазвичай не виводилися — зловмисник використовував дозвіл на торгівлю, щоб провести памп-і-дамп на неліквідній парі, купуючи на акаунт жертви за завищеними цінами та продаючи власні активи. Відсутність дозволу на виведення не означає, що активи в безпеці. Це означає, що атака зміщується від крадіжки до навмисних збитків.

Ключі за замовчуванням мають статус Readonly. Ви повинні свідомо поставити галочку для дозволу на торгівлю, що є правильним налаштуванням за замовчуванням, а також причиною, чому перший ордер часто повертає -1052 (Недостатньо дозволів). Кожен акаунт може мати до 10 груп ключів; розділяйте їх за призначенням, а не діліть один на все. Ключ лише для читання для моніторингу та окремий торговий ключ для стратегії означають, що коли щось піде не так, ви зможете ідентифікувати та відкликати лише один з них.

Створення ключа надає вам три облікові дані з трьома різними функціями:

Парольну фразу неможливо змінити або відновити. Зберігайте її в менеджері секретів разом із SecretKey, а не у файлі конфігурації у вашому репозиторії. Деталі на рівні полів знаходяться в документації WEEX з підготовки до інтеграції API.

Як підписати запит: створення заголовка ACCESS-SIGN

Приватні ендпоінти базуються на заголовку ACCESS-SIGN. Правило коротке; режим помилки полягає в тому, що один неправильний символ у конкатенації ламає все з помилкою, яка вказує не туди.

WEEX виконує конкатенацію в такому порядку, запускає HMAC SHA256 з вашим SecretKey, а потім Base64-кодує результат:

timestamp + method.toUpperCase() + requestPath + "?" + queryString + body

Коли queryString порожній, приберіть знак питання: timestamp + method + requestPath + body.

Запит глибини BTCUSDT:

String to sign: 1591089508404GET/api/v3/market/depth?symbol=BTCUSDT&limit=20
Signature = base64.encode(hmac_sha256(secretKey, message))

Три деталі спричиняють більшість невдалих інтеграцій:

1. Часова мітка в мілісекундах і повинна бути в межах 30 секунд від часу сервера. WEEX порівнює ACCESS-TIMESTAMP зі своїм годинником і відхиляє все, що виходить за межі. Хмарні інстанси мають дрейф; запитуйте час сервера при запуску і коригуйте його, замість того, щоб довіряти локальному Date.now().
2. Метод повинен бути у верхньому регістрі. Надсилання get замість GET ламає підпис, але відповідь виглядає як помилка автентифікації — що змушує людей шукати поганий ключ.
3. Символи чутливі до регістру і повинні бути у верхньому регістрі. btcusdt не нормалізується. Для ендпоінтів ордерів беріть значення символу з відповіді /products, замість того, щоб будувати його вручну.

Повний робочий приклад, включаючи конкатенацію тіла для POST-ордерів, є в документації WEEX з підписання запитів. Налаштуйте один GET, перш ніж намагатися зробити POST.

Ліміти запитів: що викликає 429 і як діяти

Перевищення ліміту повертає HTTP 429 і тягне за собою бан приблизно на 10с. WEEX не використовує один глобальний лічильник — ліміти обмежені за вимірами:

Джерело: FAQ по спотовому та ф'ючерсному API WEEX, востаннє оновлено 14.04.2026.

Дві механіки варто засвоїти. Розміщення ордерів вимірюється на акаунт (userId) і не споживає вагу IP — лічильник IP у заголовках відповідей показує 0. Все інше вимірюється за вагою IP, причому важчі ендпоінти мають більшу вагу. Тому кілька машин, що використовують одну IP-адресу, будуть конкурувати за бюджет ринкових даних, але не за бюджет ордерів.

Не оцінюйте залишок бюджету локальним лічильником. Кожна відповідь містить X-USED-WEIGHT-1M та X-REMAINING-WEIGHT-1M; запити ордерів додатково містять X-ORDER-COUNT-* та X-ORDER-REMAINING-*. Орієнтуйтеся на заголовки, а не на жорстко закодовані "5 запитів на секунду" — і зауважте, що англійська та китайська документації WEEX наразі розходяться щодо ліміту спотових ордерів (англійська каже 100/хв, китайська — 100/10с). Заголовки відповідей є єдиним джерелом істини.

Чи безпечний API криптобіржі? Три ланки в ланцюзі

Безпека тут — це властивість вашої конфігурації, а не лише біржі. Біржа володіє однією з трьох ланок.

Ланка перша: зберігання ключів. SecretKey показується один раз і більше ніколи, тому витоки відбуваються на вашій стороні — коміт у Git, вбудовування у фронтенд, запис у логи, вставка в робочий чат. Змінні середовища або менеджер секретів, плюс одне правило без винятків: ключі ніколи не передаються через месенджери.

Ланка друга: білий список IP. WEEX дозволяє прив'язувати IP-адреси при створенні ключа і прямо рекомендує це зробити. Неприв'язаний ключ працює з будь-якої точки світу в момент витоку; прив'язаний змушує зловмисника спочатку зламати ваш сервер. Не встановлюйте 0.0.0.0/0 у продакшені — це те саме, що не встановлювати його зовсім.

Ланка третя: найменші привілеї. Повертаючись до таблиці дозволів: процеси моніторингу отримують Readonly, назавжди. Спотова стратегія не має причин володіти ф'ючерсами. Це не педантичність, це контроль радіусу ураження.

Дві операційні пастки задокументовані, але їх легко пропустити:

• Новий або змінений ключ поширюється глобально приблизно 15 хвилин. Помилка дозволів одразу після налаштування зазвичай є затримкою поширення, а не помилкою конфігурації.
• Спрацювання контролю ризиків платформи — підозрілі входи, потоки недійсних запитів — може автоматично вимкнути дозволи API, а відновлення відбувається через підтримку. Не проводьте навантажувальне тестування з продакшн-ключем.

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

Спочатку тестуйте на паперовій торгівлі: п'ять помилок, що шкодять новим інтеграціям

WEEX запускає ендпоінти паперової торгівлі на ф'ючерсній стороні з використанням симульованого SUSDT, під /capi/v3/sim/ — sim/balance, sim/position/allPosition, sim/order, sim/order/history, з підтримкою хедж-режиму подвійних позицій. Запуск нової стратегії там — це найдешевша відладка, яку ви коли-небудь зробите.

Перш ніж вкладати реальний капітал, тримайте цю таблицю поруч:

Ще дві речі: WEEX наразі не підтримує торгівлю сигналами TradingView або FIX API, тому стратегії, що залежать від них, потребують іншого шляху; а ендпоінти V1/V2 застарівають, тому нова робота має бути спрямована безпосередньо на V3. Повний Q&A щодо дозволів та лімітів запитів знаходиться в FAQ по спотовому API WEEX, а розробники ф'ючерсів мають почати з документації ф'ючерсного API.

Правильний порядок інтеграції API криптобіржі

Повернемося до чотирьох питань. API криптобіржі — це програмна точка входу на біржу, розділена на публічні ендпоінти, які читають, і приватні ендпоінти, які діють. Як ви його використовуєте, залежить від того, який дозвіл ви активуєте — Readonly, Spot та Futures є незалежними, а WEEX взагалі не надає доступ до виведення через API. Як ви його викликаєте, зводиться до підписання: HMAC SHA256 плюс Base64, з допуском часової мітки у 30 секунд. Чи безпечно це — залежить від вас; біржа надає прив'язку IP та рівні дозволів, а решта — ваша операційна дисципліна.

Якщо ви запам'ятаєте одне, запам'ятайте послідовність: спочатку ключ лише для читання, щоб перевірити ринкові дані та запити, потім паперова торгівля, щоб перевірити стратегію, і лише потім дозволи на торгівлю, прив'язка IP та реальні кошти. Зміна цього порядку зазвичай коштує дорого.

Готові будувати? Почніть з центру розробників WEEX, створіть ключ, налаштуйте дозволи та працюйте з ендпоінтами V3 по одному.

FAQ

1. Чи коштує API криптобіржі грошей або чи потребує заявки?

На WEEX — ні, процес кваліфікації не застосовується — увійдіть на вебплатформу і користуйтеся, до 10 груп API-ключів на акаунт. Це відрізняється від API фондових брокерів, які зазвичай обмежують доступ вимогами до капіталу, обсягу або професійного досвіду.

2. Якщо мій API-ключ витече, чи зможе хтось вивести мої кошти?

Не через API WEEX — набір дозволів обмежений Readonly, Spot та Futures, без можливості виведення. Ключ із дозволом на торгівлю все ще може бути використаний проти вас для торгівлі на неліквідних парах, виводячи вартість як реалізовані збитки. Негайно видаліть групу ключів, якщо підозрюєте витік.

3. Чи потрібен мені API-ключ лише для ринкових даних?

Ні. Свічки, глибина, тікери та списки символів — це публічні ендпоінти, без автентифікації та з лімітами за IP. Лише ендпоінти акаунту та ордерів потребують підпису.

4. Чому абсолютно новий API-ключ повертає помилку недостатніх дозволів?

Нові або змінені ключі поширюються системою приблизно 15 хвилин. Якщо -1052 зберігається після цього часу, перевірте, чи були активовані Spot або Futures.

5. Що робити, якщо я забув парольну фразу API?

Її неможливо відновити або змінити. Видаліть групу ключів, створіть нову та оновіть кожен сервіс, що використовує ці дані.

6. Чи підтримує WEEX TradingView або FIX API?

Станом на серпень 2026 року жоден з них не підтримується. Команди, яким потрібен інституційний доступ з низькою затримкою, повинні оцінити, чи відповідають їхнім вимогам REST та WebSocket, перш ніж приймати рішення.

Попередження про ризики

Криптоактиви дуже волатильні, а програмна торгівля через API криптобіржі може призвести до часткової або повної втрати капіталу. Специфічні ризики API включають несанкціоновану активність акаунту після витоку ключа, каскадні помилкові ордери, спричинені багами стратегії або слабкою обробкою помилок, ордери, що залишилися без нагляду після бану за ліміти, та посилений ризик ліквідації при торгівлі ф'ючерсами з кредитним плечем. Впроваджуйте ретельну обробку винятків та логіку повторних спроб, прив'язуйте білі списки IP до кожного ключа, застосовуйте принцип найменших привілеїв і вкладайте лише той капітал, який можете дозволити собі втратити. Параметри ендпоінтів та ліміти запитів, описані тут, були перевірені в серпні 2026 року і можуть змінюватися з оновленнями платформи — завжди звертайтеся до поточної офіційної документації API WEEX. Ця стаття не є інвестиційною порадою.