API-ключі надають автоматизованим системам, торговим ботам, операційним скриптам, пайплайнам звітності та FIX-сесіям програмний доступ до облікових записів Вашої Організації. У цій статті описано модель дозволів API-ключів, як ключі співвідносяться з обліковими записами, як управління Організації застосовується до операцій, ініційованих ключами, а також як регулюється адміністрування самих ключів.
API-ключі — це не Учасники з обліковими даними. Вони мають власну, простішу модель дозволів:
Учасник | Ключ API | |
|---|---|---|
Автентифікація | Індивідуальний вхід з 2FA | Облікові дані API-ключа |
Доступ до інтерфейсу | Так | Ні, лише через API |
Модель дозволів | Профіль робочого процесу + ролі облікового запису | Дозволи API-ключа застосовуються до вибраних облікових записів |
Варіативність за обліковим записом | Так, ролі можуть надавати різні дозволи для різних облікових записів | Ні, дозволи ключа застосовуються однаково до всіх вибраних облікових записів |
Може створювати запити на виведення та переказ | Так, якщо дозволено | Так, якщо дозволено |
Може схвалювати запити | Так, крім власних | Ніколи |
Адміністративні робочі процеси | Так, згідно з його профілем робочого процесу | Ніколи |
Ці дві моделі свідомо розділені. Учасники отримують ролі, профілі та деталізацію на рівні облікового запису, оскільки люди накопичують різноманітні обовʼязки. Ключі працюють за простою моделлю «дозволи + облікові записи», адже автоматизація має бути вузькою, однорідною та зрозумілою з першого погляду.
API-ключ поєднує два параметри: що він може робити (його дозволи) і де (його облікові записи).
Дозволи
Група | Дозвіл | Що дозволяє |
|---|---|---|
Кошти | Запит коштів | Перегляд балансів і статусу поповнення рахунку |
Внести | Генерація адрес для внесення коштів і перегляд історії депозитів | |
Вивести | Ініціювання запитів на виведення коштів (див. «Управління та API-ключі») | |
Заробити | Розподіл і виведення з розподілу продуктів Earn | |
Ордери | Запит відкритих ордерів | Перегляд відкритих ордерів і активних угод |
Запит закритих ордерів | Перегляд архіву ордерів і завершених угод | |
Створення й зміна ордерів | Виставлення та зміна ордерів | |
Скасування та закриття ордерів | Скасування відкритих ордерів і закриття позицій | |
Адреси | Додати адресу виведення | Ініціювання запитів на додавання адрес до білого списку |
Оновити адресу для виведення коштів | Ініціювання запитів на зміну адрес у білому списку | |
Дані | Запит леджера | Перегляд історії транзакцій і леджера |
Експорт даних | Експорт даних облікового запису для звітності та звірки |
Привʼязка до облікових записів
Кожен ключ привʼязується до одного або кількох облікових записів — їх Ви обираєте під час створення ключа й можете змінити пізніше. Дозволи ключа застосовуються однаково до кожного вибраного облікового запису:
Вибір конкретного облікового запису
Приватні API-запити використовують основний обліковий запис Організації, якщо account_id не вказано:
Bash
POST /0/private/AddOrderЩоб працювати з конкретним обліковим записом, передайте account_id як параметр запиту в URL:
Bash
POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYHПередавайте його в URL, а не в тілі запиту. Явно вказаний account_id має пріоритет над резервним основним обліковим записом. Це не розширює привʼязку облікових записів або дозволи ключа. Якщо ключ не має доступу до вибраного облікового запису, запит буде відхилено.
FIX-підключення
Ключі з дозволами на ордери підтримують FIX-підключення для спот-торгівлі поряд із REST і WebSocket API. FIX-сесія має ті самі дозволи та привʼязку облікових записів, що й ключ, на якому вона працює: торгівля відбувається лише на вибраних для ключа облікових записах і в межах його дозволів. Компанії, що працюють із FIX-потоком ордерів, зазвичай виділяють окремий ключ на кожну сесію, обмежений обліковими записами відповідного торгового столу.
Торгівля через WebSocket на облікових записах, відмінних від основного, наразі недоступна для API-ключів — ця можливість поки що доступна лише Власнику. Для автоматизованого потоку ордерів на додаткових облікових записах використовуйте REST або FIX. Див. Доступність та обмеження.
Налаштування безпеки
Налаштування | Опис |
|---|---|
Термін дії ключа | Необовʼязкова дата, після якої ключ перестає працювати |
Дата початку / завершення запиту | Обмежити запити даних певним діапазоном дат |
WebSocket-підключення | Увімкнути або вимкнути потокову передачу в реальному часі |
Налаштовуване nonce window | Налаштування захисту від повторних запитів для високочастотного використання |
IP-обмеження | Обмежити використання ключа певними IP-адресами або діапазонами CIDR |
Надавайте кожному ключу мінімально необхідні дозволи, доступ до якомога меншої кількості облікових записів і найсуворіші IP-обмеження, достатні для виконання його завдань. Використовуйте окремі ключі для кожної системи — один для торгового бота, один для звітності — щоб відкликання ключа було точковим і не зачіпало інші системи.
Управління організацією поширюється як на дії ключів, так і на адміністрування самих ключів.
Що роблять ключі
Правило двох категорій для Членів застосовується до ключів так само:
Ключ може лише ініціювати керовані запити — не більше. Ключі ніколи не мають права Approve: розподіл обовʼязків вимагає участі Члена-людини для кожного підтвердження, і жоден скрипт не може замінити таке рішення. Якщо політика запиту на виведення вимагає двох підтверджень, виведення, ініційоване ключем, очікує на двох Членів — так само, як і виведення, ініційоване Членом.
Успішний виклик — це не завершене виведення
Будуйте автоматизацію з урахуванням цієї асинхронності. WithdrawFunds повертає approval_request_id разом із refid:
Bash
{
"error": [],
"result": {
"refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
"approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
}
}WithdrawStatus не означає, що виведення не подавалося.Автоматизація, яка сприймає refid як підтвердження виконання, звітуватиме про виведення як завершені, поки вони перебувають у черзі на схвалення; а звірка, що робить висновок «немає в WithdrawStatus — отже, не подавалося», буде хибною як для запитів, що очікують, так і для відхилених.
Ключі також не мають доступу до адміністративних робочих процесів. Керування доступом команди, API-ключами, обліковими записами, адресами (окрім ініціювання запитів на додавання адрес) і політиками доступне лише Учасникам.
Керування ключами
Створення, редагування та скасування API-ключів є регульованою операцією в рамках спеціального робочого процесу Manage API Keys, окремого від Manage Team & Access. Це розмежування має два аспекти:
Секретний код ключа відображається лише один раз — під час створення. Збережіть його в надійному місці, не залишаючи екрана: надалі отримати його буде неможливо.
Редагування дозволів або облікових записів ключа, а також його відкликання здійснюються в тому самому керованому порядку.