Посібник з API WEEX: налаштування, виклики, дозволи та безпека

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

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

Що таке API WEEX: швидка карта можливостей

Одним рядком: API WEEX — це канал, який дозволяє коду керувати вашим акаунтом, розділений на "публічний" та "приватний". Публічні кінцеві точки повертають ринкові дані та конфігурацію системи і не потребують автентифікації; приватні кінцеві точки обробляють розміщення ордерів, скасування та керування акаунтом, і кожен запит має бути підписаний. З точки зору продуктів, він охоплює як спотову торгівлю, так і ф'ючерси з маржею в USDT для понад 100 активів.

Вибір між REST та WebSocket залежить від того, чи хочете ви "запитати один раз" чи "постійно слухати". Перевіряйте баланс або надсилайте один ордер через REST; щоб отримувати цінові тики в реальному часі, зміни глибини або виконання ордерів, тримайте з'єднання WebSocket — це простіше і оперативніше.

Як отримати свій API-ключ WEEX

Увійдіть на веб-платформу WEEX і створіть ключ на сторінці керування API. Система генерує три речі одночасно, і вам потрібні всі три:

• APIKey — алгоритмічно згенерований ідентифікатор, фактично ваше "ім'я користувача".
• SecretKey — виданий системою приватний ключ, який використовується для підписання кожного запиту.
• Passphrase — парольна фраза, яку ви визначаєте самостійно. Занотуйте це уважно: якщо Passphrase втрачено, її неможливо відновити — вам доведеться видалити групу ключів і створити нову.

Кожен акаунт може створити до 10 груп API-ключів, що дозволяє видавати окремі ключі для кожної стратегії та середовища. Два вибори при створенні встановлюють рівень безпеки ключа: дозволи, які ви відмічаєте (наступний розділ), і IP, до якого ви прив'язуєте ключ. WEEX чітко вказує, що "необмежений" ключ без прив'язки до IP є ризиком безпеки — якщо IP вашого сервера фіксований, заповніть білий список IP.

Дозволи API WEEX: де закінчується "Тільки читання" і починається торгівля

Це розділ, який варто прочитати двічі. Новостворений API-ключ за замовчуванням має статус "Тільки читання". Щоб торгувати через API, ви повинні вручну активувати відповідний дозвіл на "Спотову" торгівлю. Занадто багато дозволів означає більші втрати у разі витоку ключа; занадто мало — і стратегія не зможе працювати. Правило одне: надавайте мінімум, який дійсно потрібен стратегії.

Одна деталь, яку легко пропустити, але яка важлива для безпеки: станом на липень 2026 року дозволи, перелічені в короткому посібнику зі спотового API WEEX, — це лише ці два: "Тільки читання" та "Спотова торгівля", без окремого перемикача "виведення". Для більшості стратегій це функція, а не прогалина: навіть якщо ключ витече, той, хто його тримає, не зможе вивести активи прямо. Ставтеся до опцій, показаних на вашій фактичній сторінці створення ключа, як до джерела істини.

Як викликати API: що потрібно для одного підписаного запиту

Весь бар'єр для приватних кінцевих точок — це крок "підписання". WEEX генерує підписи за допомогою HMAC SHA256: зашифруйте рядок перед підписанням за допомогою вашого SecretKey, а потім закодуйте результат у Base64. Рядок перед підписанням збирається у фіксованому порядку:

timestamp + method (верхній регістр) + requestPath + "?" + queryString + body

queryString опускається, якщо він порожній. Візьмемо запит глибини GET як приклад: /api/v3/market/depth?symbol=BTCUSDT&limit=20 з міткою часу 1591089508404 створює рядок перед підписанням 1591089508404GET/api/v3/market/depth?symbol=BTCUSDT&limit=20.

Після підписання кожен приватний запит несе чотири заголовки:

Приватні канали WebSocket працюють так само — підпишіть мітку часу плюс шлях запиту /v3/ws/private для входу. Місце, де більшість новачків застрягають, — це не криптографія, а мітка часу: якщо мітка часу вашого запиту відхиляється від часу сервера більше ніж на 30 секунд, запит відхиляється. Неправильний локальний годинник або застаріла кешована мітка часу видадуть незрозумілу помилку 401. Синхронізація часу NTP перед запуском заощадить половину часу на налагодження. Повні поля та приклади є в офіційному посібнику з підготовки до інтеграції та довіднику з підписів.

Ліміти запитів та правила доступу, які варто знати

Ви не можете робити запити так швидко, як хочете. Стандартний ліміт — 10 запитів/секунду, причому деякі кінцеві точки вказують власні ліміти у своїй документації; перевищення повертає помилку 429 Too Many Requests. Зважайте на основу підрахунку: автентифіковані запити вимірюються на API-ключ, неавтентифіковані — на публічний IP, що означає, що кілька скриптів "тільки читання" на одному сервері, що використовують один вихідний IP, можуть витіснити один одного з квоти публічних кінцевих точок.

Варто пам'ятати одне правило пакетної обробки: пакетний ордер, що охоплює 4 торгові пари по 10 ордерів кожна, рахується як один запит. Групування ордерів дозволяє високочастотній стратегії підвищити пропускну здатність і одночасно зберегти квоту.

Чи безпечний API WEEX? Розділяйте контрольоване від неконтрольованого

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

• Обмежуйте дозволи до мінімуму; стратегія "тільки читання" ніколи не повинна мати дозвіл на торгівлю.
• Прив'язуйте фіксований IP до кожного ключа — жодних необмежених ключів.
• Зберігайте SecretKey та Passphrase у змінних середовища або менеджері секретів, ніколи не вбудовуйте їх у клієнтський код і не комітьте в Git.
• Використовуйте різні ключі для розробки та продакшну, щоб вони не могли впливати один на одного.
• Регулярно оновлюйте ключі, і як тільки ви помітите аномальні виклики, видаліть ключ на веб-платформі — ключ можна відкликати та відновити в будь-який час, і це найшвидший спосіб зупинити втрати.
• Налаштуйте моніторинг та сповіщення про активність акаунта та обсяг викликів, щоб незвичайна частота або ордери виявлялися негайно.

Для ширшого огляду можливостей та поширених запитань дивіться пояснення WEEX про те, чи підтримує WEEX API-торгівлю в криптовалюті. Виконайте наведений вище чек-лист, і безпека API WEEX залежатиме переважно від вашої гігієни ключів, а не від чогось містичного.

Коротка версія

Шлях до API WEEX насправді простий: створіть API-ключ з мінімальними дозволами на веб-платформі ("Тільки читання" за замовчуванням, торгівля активується вручну), зберіть тріо APIKey / SecretKey / Passphrase і прив'яжіть IP; при виклику приватних кінцевих точок підписуйте за допомогою HMAC SHA256 у фіксованому форматі, надсилайте всі чотири заголовки та дотримуйтесь 30-секундного вікна мітки часу та ліміту 10 запитів на секунду; нарешті, забезпечте гігієну ключів, принцип найменших привілеїв, білий список IP та сповіщення. Щоб почати практичну роботу, виконайте свій перший запит до публічних ринкових кінцевих точок у центрі розробників WEEX, а потім додайте приватне розміщення ордерів.

FAQ

1. Чи підтримує WEEX API-торгівлю?

Так. WEEX пропонує інтерфейси REST та WebSocket для автоматизованих ринкових даних, розміщення та скасування ордерів, а також керування акаунтом, для спотової торгівлі та ф'ючерсів з маржею в USDT — підходить для квантових, сіткових та маркет-мейкінгових ботів.

2. Скільки API-ключів може створити один акаунт?

До 10 груп. Найкраще розділяти їх за стратегією та середовищем — ключ моніторингу "тільки читання", ключ для спотової торгівлі, ключ для розробки/тестування — щоб вони працювали незалежно і могли бути відкликані окремо.

3. Що робити, якщо я забув Passphrase?

Її неможливо відновити. Passphrase — це фраза, яку ви визначаєте при створенні, і система не зберігає її у відкритому вигляді. Якщо вона втрачена, ви видаляєте цю групу API-ключів і створюєте нову.

4. Чому мої приватні запити постійно відхиляються?

Найпоширеніша причина — мітка часу. Якщо мітка часу вашого запиту відхиляється від часу сервера WEEX більше ніж на 30 секунд, він відхиляється — спочатку синхронізуйте свій локальний годинник. Потім перевірте порядок рядка перед підписанням, чи назва методу у верхньому регістрі і чи присутні всі чотири заголовки.

5. Якщо мій API-ключ витече, чи зможе зловмисник вивести мої монети?

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

6. Чи є ліміти на кількість викликів?

Так. Стандартний ліміт — 10 запитів/секунду; перевищення повертає 429. Автентифіковані запити рахуються на API-ключ, а неавтентифіковані — на IP. Пакетний ордер (наприклад, 4 пари по 10 ордерів кожна) рахується як один запит, що високочастотні стратегії можуть використовувати для економії квоти.

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

Цифрові активи є високоризиковими, а програмна торгівля через API може посилити, а не зменшити ризик, що потенційно призведе до часткової або повної втрати капіталу. Ризики, специфічні для API-торгівлі, включають крадіжку або несанкціоновані ордери через виточений ключ, каскадні помилкові ордери через логічну помилку в коді, невдалі ордери через затримку мережі або зсув мітки часу, обмеження швидкості через перевищення лімітів викликів і втрату ринку, а також ризик ліквідації при використанні ф'ючерсного кредитного плеча. Завжди обмежуйте ключі принципом найменших привілеїв, прив'язуйте IP, захищайте свій SecretKey та Passphrase і ретельно тестуйте в середовищі з невеликим обсягом перед запуском. Ця стаття є лише технічним посібником з інтеграції і не є інвестиційною порадою.