Przejście z wersji Beta

Istniejące klucze API nie są unieważniane ani ponownie wystawiane. Ich dane uwierzytelniające, uprawnienia i mapowanie kont zostają przeniesione bez zmian. Istniejące wywołania, które nie przekazują parametru account_id, działają na głównym koncie Organizacji. Sprawdź, jak Twoja integracja wybiera inne konto i odczytuje odpowiedzi na żądania wypłaty.

Wybierz określone konto w razie potrzeby

Jeśli parametr account_id zostanie pominięty, prywatne żądanie jest wykonywane na głównym koncie:

Aby wykonać operację na określonym koncie, przekaż parametr 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.

Odczytaj nową odpowiedź na żądanie wypłaty

WithdrawFunds zwraca approval_request_id wraz z refid:

• Refid nie oznacza już, że wypłata została zrealizowana. Kwota jest blokowana na źródłowym koncie w momencie złożenia żądania i zostaje rozliczona dopiero po jego zatwierdzeniu.
• approval_request_id to identyfikator zatwierdzenia, na które oczekuje wypłata. Zapisz go w powiązaniu z własnym rekordem.
• 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 oznaczać wypłaty jako rozliczone, podczas gdy nadal czekają w kolejce zatwierdzeń. Pełny opis modelu znajdziesz w artykule Klucze API.

Po konwersji Twoja Organizacja dysponuje dwoma zestawami standardowych komponentów.

Profile przepływów pracy

Profil przepływu pracy określa, jakie działania Członek może wykonywać w ramach każdego zarządzanego przepływu pracy. Każdy Członek ma przypisany dokładnie jeden.

Role kont

Rola konta określa, jakie uprawnienia Członek ma na Twoich kontach. Standardowe role obejmują wszystkie bieżące i przyszłe konta – Członek z rolą Trade all może handlować na koncie, które utworzysz jutro.

Standardowe profile i role są aktualizowane wraz z produktem: gdy pojawia się nowy przepływ pracy, członkowie z danym profilem lub rolą automatycznie otrzymują odpowiedni poziom dostępu. Pełny opis modelu znajdziesz w artykule Role, profile i uprawnienia.

Jeśli uprawnienia członka nie odpowiadają żadnemu standardowemu profilowi, zostaje on przypisany do roli zawierającej dokładnie te uprawnienia, które posiadał. Członkowie z identycznymi uprawnieniami współdzielą jedną rolę, dzięki czemu Twoja Organizacja będzie miała znacznie mniej ról niż członków.

Role przyjmują nazwy od etykiet przypisanych do członków – przykładowo członek z etykietą „Trader" trafia do roli o nazwie trader. Członkowie bez etykiety trafiają do roli migrated-role. Każda taka rola ma oznaczenie migrated, co oznacza, że nazwa została wygenerowana automatycznie i możesz ją zmienić.

Dlaczego członkowie z etykietą „Admin" nie są przypisani do profilu Admin

Etykieta „Admin" w wersji Beta pozwalała na przeglądanie, inicjowanie i zatwierdzanie żądań, ale nie na samodzielne ich kończenie bez drugiego zatwierdzenia. Profil Admin obejmuje tę możliwość – jest to poziom Execute.

Zamiast przyznawać ten poziom automatycznie, członkowie ze starą etykietą trafiają do roli o nazwie beta-admin z dokładnie tymi uprawnieniami, które już mieli. Przeniesienie ich do profilu Admin to jedno przypisanie – możesz to zrobić w dowolnym momencie.

Właściciel zostaje przypisany do profilu Admin, zachowuje wszystkie dotychczasowe uprawnienia i automatycznie otrzymuje dostęp do nowych przepływów pracy. Właściciel posiada również rolę Read all, której nie można usunąć.

Jeśli celowo ograniczono uprawnienia Właściciela, decyzja ta zostaje zachowana: Właściciel otrzymuje rolę odpowiadającą jego rzeczywistym uprawnieniom, tak jak każdy inny Członek.

• Wszystkie uprawnienia każdego Członka zostają przeniesione.
• Dane uwierzytelniające kluczy API, uprawnienia i mapowanie kont zostają zachowane.
• Salda, konta i własność kont pozostają bez zmian.
• Żądania zatwierdzeń będące w toku są kontynuowane, a zasady, progi zatwierdzeń i ustawienie „zawsze wymagaj zatwierdzenia" pozostają bez zmian.
• Weryfikacja tożsamości nie ulega zmianie – nikt nie musi ponownie się logować ani otrzymywać nowego zaproszenia.
• Konwertowane są wyłącznie konta należące do Twojej Organizacji. Uprawnienia do kont spoza Organizacji pozostają bez zmian.

Wywołania bez account_id działają na głównym koncie Organizacji. Aby pobierać dane z innego konta w mapowaniu klucza, przekaż account_id tego konta w adresie URL. Zobacz sekcję „Wybierz konkretne konto w razie potrzeby".

Wywołanie utworzyło żądanie i zablokowało kwotę na koncie źródłowym. Rozliczenie następuje po zatwierdzeniu. Śledź żądanie za pomocą wartości approval_request_id zwróconej przez wywołanie lub znajdź je na stronie Żądania. Zobacz Przelewy i wypłaty.

Członkowie, których uprawnienia nie odpowiadają żadnemu standardowemu profilowi, wymagają indywidualnej roli zachowującej ich dostęp; dwóch Członków trafia na tę samą rolę tylko wtedy, gdy ich uprawnienia są identyczne. Członkowie z różnymi etykietami pozostają na oddzielnych rolach, nawet jeśli ich uprawnienia są takie same – różne etykiety sugerują, że rozróżnienie było celowe. Zbędne role można skonsolidować, przenosząc przypisanych do nich Członków na inne role i usuwając puste.

Członkowie, którzy administrują Organizacją – zarządzając dostępem zespołu, kontami lub kluczami API – są przypisywani do roli Read all, ponieważ administrowanie kontem zakłada możliwość jego przeglądania. Jeśli ten zakres jest zbyt szeroki, zastąp Read all rolą konta ograniczoną do konkretnych kont, których potrzebują.

Nie. Konwersja jest jednokierunkowa. Wszystko, co powstanie po konwersji, można edytować – każdy układ uprawnień można odtworzyć za pomocą profili i ról.