Klucze API

Klucze API nie są Członkami posiadającymi dane uwierzytelniające. Mają własny, prostszy model uprawnień:

Oba modele są celowo od siebie oddzielone. Członkowie mają role, profile i szczegółowe uprawnienia na poziomie konta, ponieważ ludzie z czasem przejmują różnorodne obowiązki. Klucze działają na zasadzie płaskiego modelu zakres–konta, ponieważ automatyzacja powinna być wąska, jednolita i łatwa do szybkiego skontrolowania.

Klucz API łączy dwa elementy: co może robić (uprawnienia) i gdzie (konta).

Uprawnienia

Mapowanie kont

Każdy klucz jest przypisany do jednego lub kilku kont – wybieranych podczas tworzenia klucza i możliwych do edycji w późniejszym czasie. Uprawnienia klucza obowiązują jednolicie na wszystkich wybranych kontach:

• 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.
• W ramach jednego klucza nie ma możliwości różnicowania uprawnień per konto. Jeśli Twoja automatyzacja musi handlować na jednym koncie, a na innym tylko odczytywać dane, użyj dwóch kluczy. Dzięki temu zakres oddziaływania każdego klucza pozostaje przejrzysty.

Wybierz konkretne konto w razie potrzeby

Prywatne żądania API domyślnie trafiają do głównego konta organizacji, gdy parametr account_id jest pominięty:

Aby wykonać operację na konkretnym koncie, podaj account_id jako parametr zapytania w adresie URL:

Przekazuj go w adresie URL, nie w treści żądania. Jawnie podany parametr account_id ma pierwszeństwo przed domyślnym kontem głównym. Nie rozszerza to mapowania kont ani uprawnień klucza. Jeśli klucz nie ma dostępu do wybranego konta, żądanie zostanie odrzucone.

Łączność FIX

Klucze z uprawnieniami do zleceń obsługują łączność FIX dla handlu spot, uzupełniając interfejsy REST i WebSocket API. Sesja FIX działa z tymi samymi uprawnieniami i mapowaniem kont co powiązany klucz – handluje wyłącznie na wybranych kontach klucza, w ramach jego uprawnień. Firmy korzystające z przepływu zleceń FIX zazwyczaj przypisują jeden klucz do jednej sesji, ograniczony do kont obsługiwanych przez dany desk.

Ustawienia bezpieczeństwa

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 ma zastosowanie do kluczy w taki sam sposób:

• Operacje bezpośrednie są wykonywane natychmiast. Handel, Earn, zapytania o saldo, zapytania do rejestru i eksport danych są realizowane od razu, w ramach uprawnień i kont klucza.
• Operacje zarządzane tworzą żądania. Wypłata lub zmiana adresu zainicjowana przez klucz trafia do tego samego procesu co ta zainicjowana przez Członka: polityka workflow decyduje, czy zostanie zrealizowana natychmiast, czy trafi do kolejki zatwierdzeń oczekujących na akceptację człowieka.

Klucz może jedynie inicjować żądania zarządzane. Klucze nigdy nie mają uprawnień do zatwierdzania – zasada rozdziału obowiązków wymaga udziału ludzkiego Członka przy każdym zatwierdzeniu, a skrypt nie może go zastąpić. Gdy polityka żądań wypłat wymaga dwóch zatwierdzeń, wypłata zainicjowana przez klucz oczekuje na dwóch Członków – dokładnie tak samo jak ta zainicjowana przez Członka.

Pomyślne wywołanie API nie oznacza zakończonej wypłaty

Buduj automatyzację z uwzględnieniem tej asynchronii. WithdrawFunds zwraca approval_request_id wraz z refid:

• refid potwierdza istnienie żądania, a nie transfer środków. Kwota zostaje zablokowana na koncie źródłowym w chwili złożenia żądania i jest rozliczana dopiero po jego zatwierdzeniu. Zobacz Środki są blokowane w chwili złożenia żądania.
• approval_request_id to identyfikator zatwierdzenia, na które oczekuje wypłata. Zapisz go wraz z własnym rekordem wypłaty.
• Wypłaty oczekujące na zatwierdzenie nie są widoczne w WithdrawStatus. Żądanie odrzucone lub wygasłe nie pozostawia żadnego rekordu wypłaty – brak wpisu w WithdrawStatus nigdy nie oznacza, że wypłata nie została złożona.

Automatyzacja traktująca refid jako potwierdzenie realizacji będzie raportować wypłaty jako rozliczone, choć wciąż czekają w kolejce zatwierdzeń, a reconciliacja wnioskująca „brak w WithdrawStatus, zatem nigdy niezłożone" będzie błędna zarówno dla żądań oczekujących, jak i odrzuconych.

Klucze nie mają również dostępu do przepływów administracyjnych. Zarządzanie dostępem zespołu, kluczami API, kontami, adresami (poza inicjowaniem żądań adresów) oraz zasadami jest zarezerwowane wyłącznie dla Członków.

Zarządzanie kluczami

Tworzenie, edytowanie i odwoływanie kluczy API to operacja zarządzana w ramach dedykowanego przepływu Manage API Keys, odrębnego od Manage Team & Access. To rozdzielenie ma znaczenie z dwóch powodów:

• Różni administratorzy. Możesz pozwolić inżynierowi operacyjnemu zarządzać kluczami bez możliwości zmiany dostępu Członków, i odwrotnie.
• Różne zasady. Zarządzanie kluczami może mieć własne wymagania dotyczące zatwierdzeń. Wiele Organizacji wymaga niezależnego zatwierdzenia przy tworzeniu lub modyfikacji klucza – nowe poświadczenie to nowy punkt dostępu do kont – przy jednoczesnym zachowaniu szybkiej ścieżki odwołania.

1. Przejdź do Kluczy API i wybierz Utwórz klucz.
2. Nadaj kluczowi nazwę odzwierciedlającą jego przeznaczenie – system, któremu służy, i wykonywane zadania – aby jego funkcja była czytelna podczas przeglądów i incydentów bezpieczeństwa.
3. Wybierz uprawnienia klucza.
4. Wybierz konta, na których klucz będzie działał. Uprawnienia dotyczą jednakowo wszystkich wybranych kont.
5. Skonfiguruj ustawienia bezpieczeństwa: datę wygaśnięcia, ograniczenia IP i okno nonce.
6. Przejrzyj i potwierdź. Jeśli zasady zarządzania kluczami API wymagają zatwierdzenia, żądanie czeka na wymagane zgody przed wydaniem klucza.

Edytowanie uprawnień lub kont klucza oraz jego unieważnienie przebiegają tą samą ścieżką zarządzania.

Wywołanie utworzyło żądanie wypłaty, które zasady dotyczące żądań wypłat wstrzymały do zatwierdzenia. Sprawdź stronę Żądania – żądanie widnieje tam z kluczem jako inicjatorem i oczekuje na zatwierdzenie przez wymaganych Członków. To model zarządzania działający zgodnie z założeniem: automatyzacja składa propozycje, ludzie zatwierdzają.

Kwota jest zablokowana na koncie źródłowym przez cały czas oczekiwania na rozpatrzenie żądania – jest już zarezerwowana na poczet wypłaty. Śledź żądanie za pomocą approval_request_id zwróconego wraz z wywołaniem.

Konto z błędem nie jest przypisane do mapowania kont tego 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ł na tym koncie, ponieważ klucze nie obsługują zróżnicowania uprawnień per konto. Jeśli zakres jest zbyt szeroki, utwórz drugi klucz przypisany wyłącznie do nowego konta.

Jeden klucz nie może mieć różnych uprawnień dla różnych kont. Utwórz dwa klucze: klucz handlowy przypisany do konta A i klucz tylko do odczytu przypisany do konta B. Węższe klucze są też łatwiejsze do audytowania i bezpieczniejsze do unieważnienia.

Przepływ pracy Zarządzanie kluczami API prawdopodobnie wymaga zatwierdzenia – żądanie jest nadal oczekujące. Klucz zostaje wydany, a jego sekret wyświetlony, dopiero po zebraniu wymaganych zatwierdzeń. Sprawdź status żądania na stronie Żądania.

Nie. Zatwierdzenie zawsze wymaga udziału człowieka – członka organizacji. To reguła systemowa, a nie konfigurowalna polityka – właśnie ona nadaje sens wielostronnym zatwierdzeniom, gdy automatyzacja inicjuje przepływ środków.