Migrarea din Beta

Cheile API existente nu sunt revocate sau reemise. Datele de autentificare, permisiunile și maparea Conturilor sunt toate păstrate. Apelurile existente care nu transmit account_id continuă pe Contul principal al Organizației. Verifică modul în care integrarea ta selectează un alt Cont și citește răspunsurile la retrageri.

Alege un cont specific când este nevoie

Când account_id este omis, o solicitare privată operează pe Contul principal:

Pentru a opera pe un Cont specific, transmite account_id ca parametru de interogare în URL:

Transmite-l în URL, nu în corpul solicitării. Un account_id explicit are prioritate față de contul principal implicit. Nu extinde maparea Conturilor sau permisiunile cheii.

Citește noul răspuns la retragere

WithdrawFunds returnează approval_request_id împreună cu refid:

• Un refid nu mai înseamnă că retragerea s-a finalizat. Suma este blocată în Contul sursă la trimiterea solicitării și se decontează doar după aprobarea acesteia.
• approval_request_id este identificatorul aprobării de care depinde retragerea. Salvează-l în propriile înregistrări.
• Retragerile care așteaptă aprobare nu apar în WithdrawStatus. O solicitare respinsă sau care expiră nu generează niciun înregistrare de retragere, astfel că absența din WithdrawStatus nu înseamnă niciodată că retragerea nu a fost trimisă.

Automatizările care tratează un refid drept confirmare a finalizării vor raporta retragerile ca decontate în timp ce acestea se află încă în coada de aprobare. Consultă Chei API pentru modelul complet.

În urma conversiei, Organizația ta dispune de două seturi de componente standard.

Workflow Profiles

Un Workflow Profile stabilește ce poate face un Membru în fiecare flux de lucru gestionat. Fiecare Membru deține exact unul.

Account Roles

Un Account Role definește ce poate face un Membru în Conturile tale. Rolurile standard acoperă toate Conturile existente și viitoare, astfel că un Membru cu Trade all poate tranzacționa și pe un Cont creat mâine.

Profilurile și rolurile standard țin pasul cu produsul: când se adaugă un flux de lucru nou, Membrii care dețin unul primesc automat nivelul corespunzător. Consultă Roluri, profiluri și permisiuni pentru modelul complet.

Dacă permisiunile unui Membru nu corespund niciunui profil standard, acesta primește un rol care păstrează exact ce avea. Membrii cu permisiuni identice împart un singur rol, astfel că Organizația ta va avea mult mai puține roluri decât Membri.

Aceste roluri preiau numele din eticheta asociată Membrului – de exemplu, un Membru etichetat „Trader" ajunge pe un rol numit trader. Membrii fără etichetă ajung pe migrated-role. Fiecare poartă un marcaj migrated, ceea ce înseamnă că numele a fost generat automat și poate fi schimbat.

De ce Membrii tăi „Admin" nu se află pe profilul Admin

Eticheta Beta „Admin" permitea vizualizarea, inițierea și aprobarea, dar nu finalizarea propriilor solicitări fără o a doua aprobare. Profilul Admin include această capacitate, respectiv nivelul Execute.

În loc să o acorde automat, Membrii cu vechea etichetă sunt plasați pe un rol numit beta-admin, care păstrează exact permisiunile pe care le aveau deja. Mutarea lor pe Admin presupune o singură atribuire, oricând decizi să o faci.

Proprietarul este plasat pe profilul Admin, păstrează toate permisiunile anterioare și preia automat fluxurile de lucru noi. Proprietarul deține, de asemenea, rolul Read all, care nu poate fi eliminat.

Dacă ai redus deliberat permisiunile Proprietarului, decizia este păstrată: Proprietarul este convertit într-un rol care reflectă permisiunile sale efective, ca orice alt Membru.

• Toate permisiunile deținute de fiecare Membru sunt păstrate.
• Date de autentificare, permisiunile și maparea Conturilor pentru cheile API sunt păstrate.
• Soldurile, Conturile și proprietatea asupra Conturilor rămân nemodificate.
• Solicitările de aprobare aflate în curs continuă, iar politicile, pragurile de aprobare și setările „necesită întotdeauna aprobare" rămân neschimbate.
• Verificarea identității nu este afectată, iar nimeni nu trebuie să se reconecteze sau să fie reinvitat.
• Sunt convertite doar Conturile aparținând Organizației tale. Orice permisiune pe un Cont din afara acesteia rămâne neschimbată.

Apelurile fără account_id folosesc Contul principal al Organizației. Pentru a raporta pe un alt Cont din maparea Conturilor cheii, transmite account_id al acelui Cont în URL. Consultă „Alege un cont specific când este necesar".

Apelul a creat o solicitare și a blocat suma pe Contul sursă. Decontarea are loc după aprobare. Urmărește solicitarea folosind approval_request_id returnat de apel sau găsește-o pe pagina Solicitări. Consultă Transferuri și retrageri.

Membrii ale căror permisiuni nu corespund unui profil standard au nevoie fiecare de un rol care le păstrează accesul, iar doi Membri sunt combinați pe un singur rol doar când permisiunile lor sunt identice. Membrii cărora le-ai atribuit etichete diferite rămân pe roluri separate chiar și atunci când permisiunile lor coincid, deoarece etichetele sugerează că distincția a fost intenționată. Rolurile inutile pot fi consolidate prin reatribuirea Membrilor și ștergerea rolului gol.

Membrii care administrează Organizația, gestionând accesul echipei, Conturile sau cheile API, sunt plasați în Read all, deoarece administrarea unui Cont implică posibilitatea de a-l vizualiza. Dacă aceasta este mai largă decât dorești, înlocuiește Read all cu un Rol de Cont limitat la Conturile specifice de care au nevoie.

Nu. Conversia este unidirecțională. Tot ce produce poate fi editat ulterior, astfel că orice configurare de acces pe care o aveai poate fi reconstruită folosind profiluri și roluri.