API-ключі надають автоматизованим системам, торговим ботам, операційним скриптам, конвеєрам звітності та торговим сесіям FIX програмний доступ до облікових записів Вашої Організації. У цій статті описано модель дозволів API-ключів, привʼязку ключів до облікових записів, застосування управління Організацією до операцій, ініційованих ключами, а також порядок адміністрування самих ключів.
API-ключі — це не Учасники з обліковими даними. Вони мають власну, простішу модель дозволів:
Учасник | Ключ API | |
|---|---|---|
Автентифікація | Індивідуальний вхід із 2FA | Облікові дані API-ключа |
Доступ до інтерфейсу | Так | Ні, лише через API |
Модель дозволів | Профіль робочого процесу + ролі облікового запису | Дозволи API-ключа, застосовані до вибраних облікових записів |
Відмінності за обліковими записами | Так, ролі можуть надавати різні дозволи для різних облікових записів | Ні, дозволи ключа однаково застосовуються до всіх вибраних облікових записів |
Може ініціювати запити на виведення та переказ | Так, якщо дозволено | Так, якщо дозволено |
Може схвалювати запити | Так, крім власних | Ніколи |
Адміністративні робочі процеси | Так, відповідно до профілю робочого процесу учасника | Ніколи |
Обидві моделі свідомо розділені. Учасники отримують ролі, профілі та деталізацію дозволів на рівні облікового запису, адже коло обовʼязків людини з часом розширюється. Ключі працюють за спрощеною моделлю «дозволи + облікові записи», адже автоматизація має бути вузькоспрямованою, однорідною та зручною для швидкого аудиту.
API-ключ поєднує два параметри: що він може робити (дозволи) і де (облікові записи).
Дозволи
Група | Дозвіл | Що дозволяє |
|---|---|---|
Кошти | Запит коштів | Переглядати баланси та статус поповнення рахунку |
Внести | Генерувати адреси для внесення коштів і переглядати історію внесень | |
Вивести | Створювати запити на виведення (див. «Управління та API-ключі») | |
Заробити | Розподіляти кошти в продукти Earn та виводити їх з розподілу | |
Ордери | Запитувати відкриті ордери | Переглядати відкриті ордери та активні угоди |
Запитувати закриті ордери | Переглядати історію ордерів і завершені угоди | |
Створення й зміна ордерів | Виставляти та змінювати ордери | |
Скасовувати та закривати ордери | Скасовувати відкриті ордери та закривати позиції | |
Адреси | Додати адресу виведення | Створювати запити на додавання адрес до білого списку |
Оновити адресу для виведення коштів | Створювати запити на зміну адрес у білому списку | |
Дані | Запитувати леджер | Переглядати історію транзакцій та леджера |
Експорт даних | Експортувати дані облікового запису для звітності та звірки |
Привʼязка до облікових записів
Кожен ключ привʼязується до одного або кількох облікових записів — вибір здійснюється під час створення ключа й може бути змінений пізніше. Дозволи ключа застосовуються однаково до всіх вибраних облікових записів:
FIX-підключення
Ключі з дозволами на роботу з ордерами підтримують FIX-підключення для спот-торгівлі поряд із REST і WebSocket API. FIX-сесія успадковує дозволи та привʼязку до облікових записів від ключа, що її забезпечує: вона торгує лише на вибраних облікових записах ключа та в межах його дозволів. Компанії, що використовують FIX-потік ордерів, як правило, виділяють окремий ключ на кожну сесію, обмежений обліковими записами відповідного торгового підрозділу.
Торгівля через WebSocket на облікових записах, відмінних від основного, наразі недоступна для API-ключів — ця можливість поки що зарезервована лише для Власника. Для автоматизованого потоку ордерів на додаткових облікових записах використовуйте REST або FIX. Див. Доступність та обмеження.
Налаштування безпеки
Налаштування | Опис |
|---|---|
Термін дії ключа | Необов'язкова дата, після якої ключ перестає працювати |
Початкова / кінцева дата запиту | Обмежити запити даних вказаним діапазоном дат |
WebSocket-зʼєднання | Увімкнути або вимкнути потокову передачу в реальному часі |
Налаштовуване nonce window | Налаштування захисту від повторних запитів для високочастотного використання |
IP-обмеження | Обмежити використання ключа певними IP-адресами або діапазонами CIDR |
Надавайте кожному ключу мінімально необхідні дозволи, найменшу кількість облікових записів і найсуворіші IP-обмеження, достатні для виконання його завдань. Використовуйте окремі ключі для кожної системи — один для торгового бота, один для звітності — щоб анулювання ключа завжди було точковим.
Управління організацією поширюється як на дії ключів, так і на керування ними.
Що роблять ключі
Правило двох категорій для учасників застосовується до ключів так само.
Ключ може лише ініціювати керовані запити. Ключі ніколи не мають повноважень на підтвердження — розподіл обовʼязків вимагає участі учасника-людини для кожного підтвердження, і жоден скрипт не може замінити таке рішення. Якщо політика запитів на виведення вимагає двох підтверджень, виведення, ініційоване ключем, очікуватиме на двох учасників — так само, як і запит від учасника.
Будуйте автоматизацію з урахуванням цієї асинхронності: успішний API-виклик означає лише те, що запит створено, а не що кошти переміщено. Відстежуйте запит до його завершення та враховуйте поточне обмеження: запит у стані очікування не резервує кошти — якщо баланс зміниться під час перевірки, підтверджений запит завершиться помилкою і його потрібно буде повторно надіслати. Див. Зберігайте кошти доступними до підтвердження.
Ключі також не мають доступу до адміністративних робочих процесів. Керування доступом команди, API-ключами, обліковими записами, адресами (крім ініціювання запитів на адреси) та політиками доступне лише учасникам.
Керування ключами
Створення, редагування та скасування API-ключів є керованою операцією в межах спеціального робочого процесу «Керування API-ключами», окремого від «Керування командою та доступом». Це розмежування має два важливі наслідки:
Секретний код ключа відображається лише один раз — під час створення. Збережіть його в надійному місці, не залишаючи цей екран, — відновити секретний код пізніше неможливо.
Редагування дозволів чи облікових записів ключа, а також його відкликання відбуваються тим самим регульованим шляхом.
Виклик створив запит на виведення, і політика запитів на виведення утримує його на погодженні. Перевірте сторінку «Запити» — запит відображається там із ключем як ініціатором і очікує на необхідні підтвердження від Учасників. Це модель управління, яка працює як задумано: автоматизація ініціює, люди затверджують.
Якщо запит було затверджено, але кошти так і не перемістилися, перевірте, чи вистачало балансу на рахунку-джерелі на момент виконання: запит в очікуванні не резервує кошти, тому операції під час перевірки можуть призвести до відхилення затвердженого запиту. Повторно подайте запит, щойно баланс відновиться.
Обліковий запис, на якому виникає помилка, не входить до переліку облікових записів ключа. Ключ діє лише на вибраних облікових записах. Відредагуйте ключ, щоб додати обліковий запис, — майте на увазі, що повний набір дозволів ключа поширюватиметься і на нього, оскільки ключі не підтримують різних дозволів для різних облікових записів. Якщо це занадто широкий доступ, створіть окремий ключ, обмежений новим обліковим записом.
Один ключ не може мати різні дозволи для різних облікових записів. Створіть два ключі: торговий ключ, привʼязаний до облікового запису A, і ключ лише для читання, привʼязаний до облікового запису B. Ключі з вужчим доступом також легше перевіряти й безпечніше відкликати.
Робочий процес Manage API Keys, імовірно, потребує підтвердження, а запит ще очікує на розгляд. Ключ видається, а його секрет відображається лише після отримання необхідних підтверджень. Перевірте статус запиту на сторінці «Запити».
Ні. Підтвердження завжди потребує участі учасника — людини. Це системне правило, а не параметр політики, — саме воно забезпечує змістовність багатостороннього підтвердження, коли автоматизація ініціює переміщення коштів.