Trecerea de la Beta

Cheile tale API existente nu sunt revocate sau reemise. Credențialele, permisiunile și maparea conturilor sunt toate transferate. Ceea ce se schimbă este modul în care codul tău abordează solicitările și citește răspunsurile.

Selectează un cont la fiecare solicitare

O cheie API de Organizație acoperă unul sau mai multe Conturi și nu are o valoare implicită, deci fiecare solicitare privată trebuie să specifice cărui Cont i se aplică. Transmite account_id ca parametru de interogare în URL, nu în corpul solicitării:

Acest lucru se aplică tranzacționării, interogărilor de sold și registru, istoricului de ordine și tranzacții, exporturilor și mișcării fondurilor, în egală măsură.

Citește noul răspuns de retragere

WithdrawFunds returnează approval_request_id alături de refid:

• Un refid nu mai înseamnă că retragerea a fost finalizată. Suma este blocată în Contul sursă atunci când solicitarea este trimisă și este decontată doar după aprobarea solicitării.
• approval_request_id este identificatorul pentru aprobarea pe care o așteaptă retragerea. Stochează-l în evidența ta.
• Retragerile în așteptarea aprobării nu apar în WithdrawStatus. O solicitare care este respinsă sau expiră nu creează deloc o înregistrare de retragere, deci absența din WithdrawStatus nu înseamnă niciodată că o retragere nu a fost trimisă.

Automatizarea care tratează un refid ca dovadă de finalizare va raporta retragerile ca decontate în timp ce acestea sunt încă în coada de aprobare. Vezi cheile API pentru modelul complet.

Organizația ta iese din conversie cu două seturi de blocuri standard de construcție.

Profile de flux de lucru

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

Roluri de cont

Un Rol de cont stabilește ce poate face un Membru în Conturile tale. Rolurile standard acoperă toate Conturile curente și viitoare, deci un Membru cu acces la „Trade all” poate tranzacționa pe un Cont pe care îl vei crea mâine.

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

În cazul în care permisiunile unui Membru nu se potrivesc cu niciun profil standard, aceștia sunt plasați într-un rol care deține exact ceea ce aveau. Membrii cu permisiuni identice partajează un singur rol, astfel încât Organizația ta va avea mult mai puține roluri decât Membri.

Aceste roluri își iau numele de la eticheta pe care ai scris-o lângă Membru, astfel încât un Membru etichetat „Trader” ajunge pe un rol numit trader. Membrii fără etichetă ajung pe migrated-role. Fiecare poartă o insignă migrată, ceea ce înseamnă că numele a fost generat și îți aparține să-l schimbi.

De ce Membrii tăi „Admin” nu sunt pe profilul de Administrator

Eticheta Beta „Admin” permitea cuiva să vizualizeze, să inițieze și să aprobe, dar nu să-și finalizeze propriile solicitări fără o a doua aprobare. Profilul de Administrator include totuși această capacitate, care este nivelul de Execuție.

În loc să le acorde automat, Membrii cu vechea etichetă sunt plasați într-un rol numit beta-admin, deținând exact permisiunile pe care le aveau deja. Mutarea lor la Administrator este o singură atribuire oricând decizi să o faci.

Proprietarul este plasat pe profilul de Administrator, păstrează tot ce avea și preia automat noi fluxuri de lucru. Proprietarul deține, de asemenea, permisiunea de a Citi tot, care nu poate fi eliminată.

Dacă ai redus în mod deliberat permisiunile Proprietarului, această decizie este păstrată: Proprietarul se convertește într-un rol deținând permisiunile sale efective, la fel ca orice alt Membru.

• Fiecare permisiune deținută de fiecare Membru este transferată.
• Datele de conectare ale cheii API, permisiunile și maparea Contului sunt păstrate.
• Soldurile, Conturile și proprietatea Contului rămân neatinsă.
• Cererile de aprobare deja în curs continuă, iar politicile, pragurile de aprobare și setările tale de „întotdeauna necesită aprobare” rămân neschimbate.
• Verificarea identității nu este afectată, și nimeni nu trebuie să se conecteze din nou sau să fie re-invitat.
• Doar Conturile aparținând Organizației tale sunt convertite. O permisiune pe orice Cont din afara acesteia rămâne așa cum este.

Cererea este aproape sigur că nu are account_id. Fără acesta, un apel privat nu se rezolvă la unul dintre Conturile cheii și poate răspunde cu un rezultat gol, mai degrabă decât o eroare. Adaugă account_id la URL și reverifică fiecare endpoint apelat de integrarea ta, nu doar pe cele care au eșuat vizibil. Vezi Chei API.

Apelul a creat o cerere și a blocat suma în Contul sursă. Decontarea urmează aprobării. Urmărește cererea cu approval_request_id returnat de apel, sau găsește-o pe pagina de Cereri. Vezi Transferuri și retrageri.

Membrii ale căror permisiuni nu corespundeau unui profil standard au nevoie fiecare de un rol care să le păstreze accesul, iar doi Membri sunt fuzionați într-un singur rol doar atunci când permisiunile lor sunt identice. Membrii cărora le-ai dat etichete diferite rămân pe roluri separate chiar și atunci când permisiunile lor se potrivesc, deoarece etichetele sugerează că distincția a fost intenționată. Rolurile de care nu ai nevoie pot fi consolidate prin realocarea Membrilor acestora ș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 vedea. Dacă acest lucru este mai larg decât îți dorești, înlocuiește Read all cu un Rol de Cont (Account Role) alocat Conturilor specifice de care au nevoie.

Nu. Conversia este într-un singur sens. Tot ceea ce produce este editabil ulterior, deci orice aranjament de acces pe care îl aveai poate fi reconstruit utilizând profile și roluri.