Overgang fra Beta

Denne artikkelen er for organisasjoner opprettet under Beta-tilgangsmodellen, der en administrator tildelte tillatelser til hvert medlem individuelt. Tilgang er nå bygget på Arbeidsflytprofiler og Kontoroller, og Kraken konverterer organisasjonen din for deg.

To ting krever din oppmerksomhet før konverteringen:

  • Hvis du bruker API-nøkler, må integrasjonene dine oppdateres først. Måten forespørsler velger en konto på, har endret seg, og et vellykket uttaksanrop betyr ikke lenger at midlene er flyttet. Se «Oppdater API-integrasjonene dine» nedenfor.
  • Vi vil be deg om å bekrefte at du er klar. Organisasjonen din blir ikke konvertert før du godtar endringen.

Ingenting i konverteringen fjerner tilgang. Hver tillatelse hvert medlem hadde, overføres.

Dine eksisterende API-nøkler blir ikke tilbakekalt eller gjenutstedt. Deres legitimasjon, tillatelser og kontotilordning overføres. Det som endrer seg, er hvordan koden din adresserer forespørsler og leser svar.

Velg en konto ved hver forespørsel

En organisasjons API-nøkkel dekker én eller flere kontoer og har ingen standardverdi, så hver private forespørsel må spesifisere hvilken konto den gjelder for. Send account_id som en spørreparameter i URL-en, ikke i forespørselsteksten:

bash

Bash

POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYH

Dette gjelder for handel, saldo- og hovedbokforespørsler, ordre- og handelshistorikk, eksport og pengebevegelser.

Advarsel:

Test hver samtalevei i et ikke-produksjonsmiljø før du bytter over, inkludert de du ikke forventer å ha endret. En privat forespørsel som utelater account_id kan returnere et vellykket, men tomt resultat i stedet for en feil, som lett kan misforstås som en konto uten aktivitet.

Les den nye uttaksresponsen

WithdrawFunds returnerer approval_request_id sammen med refid:

bash

Bash

{
  "error": [],
  "result": {
    "refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
    "approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
  }
}
  • En refid betyr ikke lenger at uttaket er fullført. Beløpet er låst på kildekontoen når forespørselen sendes inn, og det blir først avgjort etter at forespørselen er godkjent.
  • approval_request_id er håndtaket for godkjenningen uttaket venter på. Lagre den mot din egen oversikt.
  • Uttak som venter på godkjenning vises ikke i WithdrawStatus. En forespørsel som avvises eller utløper, oppretter ingen uttaksregistrering i det hele tatt, så fravær fra WithdrawStatus betyr aldri at et uttak ikke ble sendt inn.

Automatisering som behandler en refid som bevis på fullføring, vil rapportere uttak som avgjort mens de fortsatt er i godkjenningskøen. Se API-nøkler for den fullstendige modellen.

Organisasjonen din kommer ut av konverteringen med to sett med standard byggeklosser.

Arbeidsflytprofiler

En arbeidsflytprofil definerer hva et medlem kan gjøre i hver styrt arbeidsflyt. Hvert medlem har nøyaktig én.

Profil

Hva den inneholder

Administrator

Hvert nivå i hver arbeidsflyt, inkludert Utfør

Initiator

Se og initier i hver arbeidsflyt. Kan ikke godkjenne

Godkjenner

Se og godkjenn i hver arbeidsflyt. Kan ikke initiere

Revisor

Se i hver arbeidsflyt. Kan ikke utføre handlinger

Midleransvarlig

Se, initier og godkjenn uttaksforespørsler og overføringsforespørsler. Se og initier på administrering av adresser

Kontoroller

En kontorolle definerer hva et medlem kan gjøre på kontoene dine. Standardrollene dekker alle nåværende og fremtidige kontoer, slik at et medlem med rollen «Handle alle» kan handle på en konto du oppretter i morgen.

Rolle

Hva det gir på hver konto

Les alt

Les

Handle alt

Handle

Alle midler

Overfør, ta ut, tildel til Earn, frigjør fra Earn

Full tilgang

Alle kontotillatelser

Standardprofiler og -roller holder tritt med produktet: når en ny arbeidsflyt legges til, får medlemmer som innehar en av dem, automatisk det passende nivået. Se Roller, profiler og tillatelser for den komplette modellen.

Der et medlems tillatelser ikke samsvarer med en standardprofil, blir de plassert på en rolle som har nøyaktig de tillatelsene de hadde. Medlemmer med identiske tillatelser deler en enkelt rolle, slik at organisasjonen din vil ha langt færre roller enn medlemmer.

Disse rollene får navnet sitt fra etiketten du hadde skrevet ved siden av medlemmet, så et medlem merket “Trader” havner på en rolle kalt trader. Medlemmer uten etikett havner på migrated-role. Hver av dem har et migrert-merke, som betyr at navnet ble generert og er ditt å endre.

Tips:

Å omdøpe disse rollene slik at de samsvarer med det du faktisk kaller disse personene, er den beste første oppgaven etter konverteringen. Redigering av en rolle fjerner det migrerte merket.

Hvorfor “administrator”-medlemmene dine ikke er på administratorprofilen

Beta-etiketten “Admin” lot noen se, starte og godkjenne, men ikke fullføre egne forespørsler uten en andre godkjenning. Administratorprofilen inkluderer den muligheten, som er Execute-nivået.

I stedet for å gi det automatisk, blir medlemmer med den gamle etiketten plassert på en rolle kalt beta-admin som har nøyaktig de tillatelsene de allerede hadde. Å flytte dem til Admin er en enkelt tildeling når du bestemmer deg for det.

Merk:

beta-admin er en av dine egne roller, så medlemmer som innehar den, vil ikke automatisk plukke opp nye arbeidsflyter slik standardprofilene gjør. Dette er en annen grunn til å gjennomgå disse rollene kort tid etter konverteringen.

Eieren er plassert på administratorprofilen, beholder alt de hadde, og plukker opp nye arbeidsflyter automatisk. Eieren har også «Les alt»-tillatelse, som ikke kan fjernes.

Hvis du bevisst hadde redusert eierens tillatelser, bevares den avgjørelsen: eieren konverteres til en rolle som innehar deres faktiske tillatelser, som ethvert annet medlem.

  • Alle tillatelser hvert medlem hadde, overføres.
  • API-nøkkellegitimasjon, tillatelser og kontokartlegging bevares.
  • Saldoer, kontoer og kontoeierskap er uberørt.
  • Godkjenningsforespørsler som allerede er under behandling fortsetter, og retningslinjene dine, godkjenningsterskler og innstillinger for “alltid kreve godkjenning” er uendret.
  • Identitetsverifisering påvirkes ikke, og ingen trenger å logge på igjen eller bli invitert på nytt.
  • Bare kontoer som tilhører organisasjonen din konverteres. En tillatelse på en hvilken som helst konto utenfor den, forblir som den er.

Feilsøking

Forespørselen mangler nesten helt sikkert account_id. Uten den vil et privat anrop ikke løses til en av nøkkelens kontoer og kan svare med et tomt resultat i stedet for en feil. Legg til account_id i URL-en og dobbeltsjekk alle endepunktene integrasjonen din anroper, ikke bare de som synlig mislyktes. Se API-nøkler.

Anropet opprettet en forespørsel og låste beløpet på kildekontoen. Oppgjør følger godkjenning. Spor forespørselen med approval_request_id som returneres av anropet, eller finn den på siden Forespørsler. Se Overføringer og uttak.

Medlemmer hvis tillatelser ikke samsvarte med en standardprofil, trenger hver en rolle som bevarer deres tilgang, og to medlemmer slås kun sammen til én rolle når deres tillatelser er identiske. Medlemmer du hadde gitt forskjellige merkelapper, forblir på separate roller selv der tillatelsene deres samsvarer, fordi merkelappene antyder at skillet var tilsiktet. Roller du ikke trenger, kan konsolideres ved å omfordele medlemmene og slette den tomme rollen.

Medlemmer som administrerer organisasjonen, som administrerer teamtilgang, kontoer eller API-nøkler, plasseres i 'Les alle', fordi administrering av en konto innebærer å kunne se den. Hvis dette er bredere enn du ønsker, erstatter du 'Les alle' med en kontorolle begrenset til de spesifikke kontoene de trenger.

Nei. Konverteringen er enveis. Alt den produserer kan redigeres etterpå, så enhver tilgangsordning du hadde, kan gjenoppbygges ved hjelp av profiler og roller.

Relaterte artikler

Trenger du mer hjelp?