All
Filtruj według:
Jak mogę wpłacić gotówkę na konto?
Potrzebuję pomocy w weryfikacji konta
Dlaczego nie mogę uzyskać dostępu do konta?
Czy są jakieś opłaty za wypłatę kryptowalut?
Potrzebuję pomocy w zalogowaniu się na konto
Klucze API
Klucze API zapewniają zautomatyzowanym systemom, botom handlowym, skryptom operacyjnym, potokom raportowania i sesjom handlowym FIX programowy dostęp do kont Twojej Organizacji. Artykuł omawia model uprawnień kluczy API, sposób przypisywania kluczy do kont, zasady zarządzania Organizacją w odniesieniu do operacji inicjowanych przez klucze oraz zarządzanie samymi kluczami.
Klucze API nie są Członkami posiadającymi dane uwierzytelniające. Działają według własnego, prostszego modelu uprawnień:
Członek | Klucz API | |
|---|---|---|
Uwierzytelnianie | Indywidualne logowanie z weryfikacją 2FA | Dane uwierzytelniające klucza API |
Dostęp do interfejsu | Tak | Nie, wyłącznie API |
Model uprawnień | Profil przepływu pracy + role konta | Uprawnienia klucza API przypisane do wybranych kont |
Zróżnicowanie uprawnień według konta | Tak – role mogą nadawać różne uprawnienia na różnych kontach | Nie – uprawnienia klucza obowiązują jednolicie na wszystkich wybranych kontach |
Może inicjować żądania wypłat i przelewów | Tak, gdy jest to dozwolone | Tak, gdy jest to dozwolone |
Może zatwierdzać żądania | Tak, z wyjątkiem własnych | Nigdy |
Przepływy pracy administracyjnej | Tak, zgodnie z przypisanym profilem przepływu pracy | Nigdy |
Oba modele są celowo rozdzielone. Członkowie otrzymują role, profile i szczegółowe uprawnienia per konto, ponieważ z czasem kumulują różnorodne obowiązki. Klucze działają według płaskiego modelu zakres–konta, ponieważ automatyzacja powinna być wąska, jednolita i łatwa do audytu na pierwszy rzut oka.
Klucz API opiera się na dwóch wyborach: co może robić (uprawnienia) i gdzie (konta).
Uprawnienia
Grupa | Uprawnienie | Co umożliwia |
|---|---|---|
Środki | Zapytanie o środki | Podgląd sald i statusu środków |
Wpłata | Generuj adresy do wpłat i przeglądaj historię wpłat | |
Wypłata | Inicjuj żądania wypłaty (patrz „Zarządzanie i klucze API") | |
Zarabiaj | Alokuj produkty Earn i usuń ich alokację | |
Zlecenia | Pobierz otwarte zlecenia | Podgląd otwartych zleceń i aktywnych transakcji |
Pobierz zamknięte zlecenia | Podgląd historii zleceń i zrealizowanych transakcji | |
Twórz i modyfikuj zlecenia | Składaj i modyfikuj zlecenia | |
Anuluj i zamknij zlecenia | Anuluj otwarte zlecenia i zamknij pozycje | |
Adresy | Dodaj adres wypłaty | Inicjuj żądania dodania adresów z białej listy |
Zaktualizuj adres wypłaty | Inicjuj żądania zmiany adresów z białej listy | |
Dane | Pobierz dane rejestru | Podgląd historii transakcji i rejestru |
Eksportuj dane | Eksportuj dane konta do raportowania i uzgodnień |
Mapowanie kont
Każdy klucz jest przypisany do jednego lub kilku kont – wybieranych podczas tworzenia klucza i możliwych do edycji później. Uprawnienia klucza obowiązują jednolicie dla wszystkich wybranych kont:
- Klucz z uprawnieniami Zapytanie o środki oraz Tworzenie i modyfikowanie zleceń na dwóch wybranych kontach może odczytywać salda i handlować na obu – i nic więcej.
- Jeden klucz nie pozwala na różnicowanie uprawnień między kontami. Jeśli Twoja automatyzacja ma handlować na jednym koncie, a jedynie odczytywać dane z drugiego, użyj dwóch kluczy. Dzięki temu zasięg działania każdego klucza pozostaje przejrzysty.
Łączność FIX
Klucze z uprawnieniami do zleceń obsługują łączność FIX dla handlu spot, obok interfejsów REST i WebSocket API. Sesja FIX dziedziczy uprawnienia i przypisanie kont powiązanego klucza – realizuje transakcje wyłącznie na wybranych kontach klucza i w granicach jego uprawnień. Firmy obsługujące zlecenia przez FIX zazwyczaj przydzielają jeden klucz na sesję, ograniczony do kont, na których operuje dany desk.
Uwaga:
Handel przez WebSocket na kontach innych niż konto główne nie jest jeszcze dostępny dla kluczy API – na razie pozostaje to funkcja zarezerwowana wyłącznie dla Właściciela. Automatyczny przepływ zleceń na dodatkowych kontach powinien korzystać z REST lub FIX. Zobacz Dostępność i ograniczenia.
Ustawienia bezpieczeństwa
Ustawienie | Opis |
|---|---|
Wygaśnięcie klucza | Opcjonalna data, po której klucz przestaje działać |
Data początkowa / końcowa zapytania | Ogranicza zapytania o dane do wskazanego zakresu dat |
Połączenia WebSocket | Włącza lub wyłącza strumieniowanie danych w czasie rzeczywistym |
Niestandardowe okno nonce | Dostrajanie ochrony przed atakami powtórzeniowymi przy dużej częstotliwości żądań |
Ograniczenia IP | Ogranicz użycie klucza do określonych adresów IP lub zakresów CIDR |
Wskazówka:
Każdemu kluczowi nadawaj możliwie najwęższy zakres uprawnień, przypisuj minimalną liczbę kont i stosuj jak najściślejsze ograniczenia IP – wystarczające do wykonania jego zadania. Twórz osobne klucze dla każdego systemu – jeden dla bota handlowego, jeden do raportowania – by unieważnianie było precyzyjne.
Zarządzanie organizacją obejmuje zarówno działania kluczy, jak i sposób zarządzania nimi.
Co robią klucze
Zasada dwóch kategorii obowiązująca Członków dotyczy kluczy w taki sam sposób:
- Operacje bezpośrednie są wykonywane natychmiast. Handel, Earn, zapytania o saldo, zapytania do rejestru i eksporty danych są realizowane od razu – w ramach uprawnień klucza i przypisanych kont.
- Operacje zarządzane tworzą żądania. Wypłata lub zmiana adresu zainicjowana przez klucz trafia do tego samego procesu co żądanie złożone przez Członka: polityka workflow decyduje, czy zostanie ono zrealizowane natychmiast, czy przekazane do kolejki zatwierdzeń oczekującej na weryfikację przez człowieka.
Klucz może jedynie inicjować żądania objęte zarządzaniem. Klucze nigdy nie mają uprawnienia Zatwierdź – rozdzielność obowiązków wymaga, aby każde zatwierdzenie wykonał Członek będący człowiekiem, a skrypt nie może go w tym zastąpić. Jeśli polityka żądania wypłaty wymaga dwóch zatwierdzeń, wypłata zainicjowana przez klucz oczekuje na zatwierdzenie przez dwóch Członków – dokładnie tak jak żądanie zainicjowane przez Członka.
Projektuj automatyzację z uwzględnieniem tej asynchroniczności: pomyślne wywołanie API oznacza jedynie, że żądanie zostało utworzone – nie że środki zostały przetransferowane. Śledź żądanie aż do jego realizacji i uwzględnij bieżące ograniczenie: oczekujące żądanie nie rezerwuje środków – jeśli saldo zmieni się w trakcie weryfikacji, zatwierdzone żądanie zakończy się niepowodzeniem i trzeba je będzie złożyć ponownie. Zobacz Utrzymuj środki dostępne do momentu zatwierdzenia.
Klucze nie mają również dostępu do administracyjnych przepływów pracy. Zarządzanie dostępem zespołu, kluczami API, kontami, adresami (poza inicjowaniem żądań adresowych) i politykami jest zastrzeżone wyłącznie dla Członków.
Zarządzanie kluczami
Tworzenie, edytowanie i unieważnianie kluczy API to operacje objęte zarządzaniem, realizowane w ramach dedykowanego przepływu pracy Manage API Keys, odrębnego od Manage Team & Access. Rozdzielenie to ma znaczenie z dwóch powodów:
- Różni administratorzy. Możesz pozwolić inżynierowi operacyjnemu zarządzać kluczami bez możliwości modyfikowania dostępów Członków – i odwrotnie.
- Różne polityki. Zarządzanie kluczami może podlegać własnym wymaganiom dotyczącym zatwierdzeń. Wiele organizacji wymaga niezależnego zatwierdzenia przy tworzeniu lub modyfikowaniu klucza – nowe poświadczenie to nowa droga dostępu do kont – zachowując jednocześnie możliwość szybkiego unieważnienia.
- Przejdź do kluczy API i wybierz Utwórz klucz.
- Nadaj kluczowi nazwę opisującą jego przeznaczenie – system, któremu służy, i co robi – aby jego funkcja była oczywista podczas przeglądów i zdarzeń bezpieczeństwa.
- Wybierz uprawnienia klucza.
- Wybierz konta, na których klucz ma działać. Uprawnienia obowiązują jednolicie na wszystkich wybranych kontach.
- Skonfiguruj ustawienia bezpieczeństwa: datę wygaśnięcia, ograniczenia IP, okno nonce.
- Przejrzyj i potwierdź. Jeśli polityka Zarządzaj kluczami API wymaga zatwierdzenia, żądanie oczekuje na wymagane zatwierdzenia, a klucz zostaje wydany dopiero po ich udzieleniu.
Uwaga:
Sekret klucza jest wyświetlany jednorazowo – w chwili jego utworzenia. Zapisz go bezpiecznie przed opuszczeniem ekranu – późniejsze jego odzyskanie nie jest możliwe.
Edytowanie uprawnień lub kont klucza oraz jego unieważnianie przebiega tą samą ścieżką zarządzania.
Rozwiązywanie problemów
Wywołanie spowodowało utworzenie żądania wypłaty, które polityka żądań wypłat wstrzymała do momentu zatwierdzenia. Sprawdź stronę Żądania – żądanie widnieje tam z kluczem jako inicjatorem i oczekuje na wymagane zatwierdzenia Członków. To model zarządzania działający zgodnie z założeniami: automatyzacja zgłasza, ludzie zatwierdzają.
Jeśli żądanie zostało zatwierdzone, a środki nadal nie wpłynęły, sprawdź, czy saldo źródłowe pokrywało kwotę w chwili realizacji – oczekujące żądanie nie rezerwuje środków, więc aktywność na koncie podczas przeglądu może spowodować niepowodzenie zatwierdzonego żądania. Prześlij żądanie ponownie, gdy saldo zostanie uzupełnione.
Konto, na którym pojawiają się błędy, nie jest przypisane do mapowania kont klucza. Klucz działa wyłącznie na przypisanych do niego kontach. Edytuj klucz, aby dodać konto – pamiętaj, że pełny zestaw uprawnień klucza będzie obowiązywał również tam, ponieważ klucze nie obsługują zróżnicowania uprawnień na poziomie konta. Jeśli zakres jest zbyt szeroki, utwórz drugi klucz przypisany do nowego konta.
Jeden klucz nie może mieć różnych uprawnień dla różnych kont. Utwórz dwa klucze: klucz transakcyjny przypisany do konta A i klucz tylko do odczytu przypisany do konta B. Węższe klucze są też łatwiejsze do audytu i bezpieczniejsze do unieważnienia.
Przepływ pracy Zarządzaj kluczami API prawdopodobnie wymaga zatwierdzenia, a żądanie jest nadal w toku. Klucz zostaje wydany, a jego sekret wyświetlony dopiero po zebraniu wymaganych zatwierdzeń. Sprawdź status żądania na stronie Żądań.
Nie. Zatwierdzenie zawsze wymaga udziału człowieka – Członka organizacji. To reguła systemowa, a nie konfigurowalna zasada – właśnie ona nadaje sens wielostronnemu zatwierdzaniu, gdy automatyzacja inicjuje transfery środków.