Overgang fra Beta

Sist oppdatert: 20. august 2026

Denne artikkelen gjelder organisasjoner opprettet under Beta-tilgangsmodellen, der en administrator ga tillatelser til hvert enkelt medlem. Tilgang bygges nå fra Workflow Profiles og Account Roles, og Kraken konverterer organisasjonen din for deg.

To ting krever oppmerksomheten din før konverteringen:

  • Hvis du bruker API-nøkler, gjennomgå hvordan de oppfører seg i organisasjonen din. Eksisterende kall fortsetter på primærkontoen. Bruk account_id til å velge en annen konto, og behandle et vellykket uttaksanrop som en forespørsel – ikke som bevis på at midlene er overført. Se «Gjennomgå API-atferden din» nedenfor.
  • Vi ber deg bekrefte at du er klar. Organisasjonen din konverteres ikke før du godtar endringen.

Konverteringen fjerner ingen tilganger. Alle tillatelser hvert medlem hadde, overføres.

Eksisterende API-nøkler verken trekkes tilbake eller utstedes på nytt. Påloggingsopplysninger, tillatelser og kontotilordning overføres som de er. Eksisterende kall som ikke sender account_id, fortsetter på organisasjonens primærkonto. Gjennomgå hvordan integrasjonen din velger en annen konto og leser uttakssvar.

Velg en bestemt konto ved behov

Når account_id utelates, opererer en privat forespørsel på primærkontoen:

bash

Bash

POST /0/private/AddOrder

For å utføre handlinger på en bestemt konto sender du account_id som en spørringsparameter i URL-en:

bash

Bash

POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYH

Send den i URL-en, ikke i forespørselsteksten. En eksplisitt account_id har forrang over primærkonto-fallback. Den utvider ikke nøkkelens kontotilordning eller tillatelser.

Les det nye uttakssvaret

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 gjennomført. Beløpet låses på kildekontoen når forespørselen sendes inn, og gjøres opp først etter at forespørselen er godkjent.
  • approval_request_id er håndtaket for godkjenningen uttaket venter på. Lagre den mot din egen registrering.
  • Uttak som venter på godkjenning vises ikke i WithdrawStatus. En forespørsel som avvises eller utløper, oppretter ingen uttaksregistrering, så fravær fra WithdrawStatus betyr aldri at et uttak ikke ble sendt inn.

Automatisering som bruker en refid som bevis på gjennomføring, vil rapportere uttak som oppgjort mens de fortsatt ligger i godkjenningskøen. Se API-nøkler for den fullstendige modellen.

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

Workflow Profiles

En Workflow Profile definerer hva et Medlem kan gjøre i hver styrt arbeidsflyt. Hvert Medlem har nøyaktig én.

Profil

Hva den inneholder

Admin

Alle nivåer i alle arbeidsflyter, inkludert Execute

Begynner

Vis og start i alle arbeidsflyter. Kan ikke godkjenne

Approver

Vis og godkjenn i alle arbeidsflyter. Kan ikke starte

Auditor

Vis i alle arbeidsflyter. Kan ikke utføre handlinger

Funds Manager

Vis, initier og godkjenn for Uttaksforespørsel og Overføringsforespørsel. Vis og initier for Administrer adresser

Kontoroller

En kontorolle angir hva et medlem kan gjøre på kontoene dine. Standardrollene dekker alle eksisterende og fremtidige kontoer, slik at et medlem med rollen Handel alle kan handle på en konto du oppretter i morgen.

Rolle

Hva den gir på alle kontoer

Les alle

Les

Handel alle

Handel

Midler alle

Overføring, ta ut, Tjen – alloker, Tjen – deallokere

Full tilgang

Alle kontotillatelser

Standardprofiler og -roller følger produktutviklingen: når en ny arbeidsflyt legges til, får medlemmer med en slik profil eller rolle automatisk riktig tilgangsnivå. Se Roller, profiler og tillatelser for den fullstendige modellen.

Når et medlems tillatelser ikke samsvarer med noen standardprofil, tildeles medlemmet en rolle som inneholder nøyaktig de tillatelsene vedkommende hadde. Medlemmer med identiske tillatelser deler én og samme rolle, så organisasjonen din vil ha langt færre roller enn medlemmer.

Rollene får navn fra etiketten du hadde satt på medlemmet, slik at et medlem merket «Trader» havner i en rolle kalt trader. Medlemmer uten etikett havner på migrated-role. Hver av disse har et migrated-merke, som betyr at navnet er autogenerert og kan endres.

Tips:

Det beste første steget etter konverteringen er å gi disse rollene navn som faktisk gjenspeiler hva du kaller personene. Når du redigerer en rolle, fjernes migrated-merket.

Hvorfor «Admin»-medlemmene dine ikke er på Admin-profilen

Beta-etiketten «Admin» ga noen mulighet til å vise, initiere og godkjenne, men ikke fullføre egne forespørsler uten en ekstra godkjenning. Admin-profilen inkluderer denne muligheten, som tilsvarer Execute-nivået.

I stedet for å gi dette automatisk plasseres medlemmer med den gamle etiketten i en rolle kalt beta-admin med nøyaktig de tillatelsene de allerede hadde. Du kan flytte dem til Admin med én enkelt tildeling når du er klar.

Merk:

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

Eieren plasseres på Admin-profilen, beholder alt de hadde, og får nye arbeidsflyter automatisk. Eieren har også Read all, som ikke kan fjernes.

Hvis du bevisst hadde begrenset eierens tillatelser, bevares det valget: eieren konverteres til en rolle med sine faktiske tillatelser, som alle andre medlemmer.

  • Alle tillatelser hvert medlem hadde, overføres.
  • Påloggingsopplysninger, tillatelser og kontotilordning for API-nøkler beholdes.
  • Saldo, kontoer og kontoeierskap er uendret.
  • Godkjenningsforespørsler som allerede er under behandling, fortsetter som normalt, og retningslinjene, godkjenningstersklene og innstillingene for «krev alltid godkjenning» er uendret.
  • Identitetsverifisering påvirkes ikke, og ingen trenger å logge inn på nytt eller inviteres på nytt.
  • Bare kontoer som tilhører organisasjonen din, konverteres. Tillatelser på kontoer utenfor organisasjonen beholdes som de er.

Feilsøking

Kall uten account_id bruker organisasjonens primære konto. For å rapportere på en annen konto i nøkkelens kontotilordning, send den kontoens account_id i URL-en. Se «Velg en bestemt konto ved behov».

Kallet opprettet en forespørsel og låste beløpet på kildekontoen. Oppgjør skjer etter godkjenning. Spor forespørselen med approval_request_id fra kallet, eller finn den på Forespørsler-siden. Se Overføringer og uttak.

Medlemmer hvis tillatelser ikke samsvarer med en standardprofil trenger hver sin rolle som bevarer tilgangen deres, og to medlemmer slås bare sammen i én rolle når tillatelsene deres er identiske. Medlemmer du har gitt ulike etiketter beholdes på separate roller selv der tillatelsene stemmer overens, fordi etikettene antyder at forskjellen var tilsiktet. Roller du ikke trenger, kan konsolideres ved å flytte medlemmene til andre roller og slette den tomme rollen.

Medlemmer som administrerer organisasjonen – håndterer teamtilgang, kontoer eller API-nøkler – plasseres i «Les alle», fordi administrasjon av en konto forutsetter at man kan se den. Hvis det er bredere enn du ønsker, erstatter du «Les alle» med en kontorrolle avgrenset til de spesifikke kontoene vedkommende trenger.

Nei. Konverteringen er enveis. Alt konverteringen produserer kan redigeres i etterkant, så enhver tilgangsordning du hadde kan bygges opp igjen ved hjelp av profiler og roller.

Relaterte artikler