Skift fra beta

Denne artikel er til organisationer, der er oprettet under betaadgangsmodellen, hvor en administrator tildelte tilladelser til hvert medlem individuelt. Adgang bygges nu ud fra Workflow Profiles og Account Roles, og Kraken konverterer din organisation for dig.

To ting kræver din opmærksomhed før konverteringen:

  • Hvis du bruger API-nøgler, skal dine integrationer opdateres først. Måden anmodninger vælger en konto på er ændret, og et succesfuldt udbetalingskald betyder ikke længere, at midlerne er flyttet. Se „Opdater dine API-integrationer“ nedenfor.
  • Vi vil bede dig om at bekræfte, at du er klar. Din organisation konverteres ikke, før du accepterer ændringen.

Intet i konverteringen fjerner adgang. Hver tilladelse, som hvert medlem havde, overføres.

Dine eksisterende API-nøgler tilbagekaldes eller genudstedes ikke. Deres legitimationsoplysninger, tilladelser og kontotilknytning overføres alle. Det, der ændres, er, hvordan din kode adresserer anmodninger og læser svar.

Vælg en konto for hver anmodning

En organisations-API-nøgle dækker en eller flere konti og har ingen standard, så hver privat anmodning skal angive, hvilken konto den gælder for. Send account_id som en forespørgselsparameter i URL'en, ikke i anmodningsbody'en:

bash

Bash

POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYH

Dette gælder for handel, saldobalance og hovedbog forespørgsler, ordre- og handelshistorik, eksport og pengebevægelser.

Forsigtig:

Test hver kaldssti i et ikke-produktionsmiljø, før du skifter over, inklusive dem du ikke forventer er ændret. En privat anmodning, der udelader account_id, kan returnere et succesfuldt, men tomt resultat i stedet for en fejl, hvilket let kan misfortolkes som en konto uden aktivitet.

Læs det nye udbetalingssvar

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 betyder ikke længere, at udbetalingen er gennemført. Beløbet er låst på kildekontoen, når anmodningen indsendes, og det afregnes først, når anmodningen er godkendt.
  • `approval_request_id` er håndtaget til den godkendelse, som udbetalingen afventer. Gem det i din egen registrering.
  • Udbetalinger, der afventer godkendelse, vises ikke i WithdrawStatus. En anmodning, der afvises eller udløber, opretter slet ingen udbetalingspost, så fravær fra WithdrawStatus betyder aldrig, at en udbetaling ikke blev indsendt.

Automatisering, der behandler en refid som bevis for gennemførelse, vil rapportere udbetalinger som afgjort, mens de stadig er i godkendelseskøen. Se API-nøgler for den fulde model.

Din organisation kommer ud af konverteringen med to sæt standard byggesten.

Workflow Profiles

En Workflow Profile angiver, hvad et medlem kan gøre på hver styret workflow. Hvert medlem har præcis én.

Profil

Hvad den indeholder

Administrator

Hvert niveau på hver workflow, inklusive udførsel

Initiator

Se og igangsæt på hver workflow. Kan ikke godkende

Godkender

Se og godkend på hver workflow. Kan ikke igangsætte

Revisor

Se på hver workflow. Kan ikke handle

Midler-administrator

Se, igangsæt og godkend på udbetalingsanmodning og overførselsanmodning. Se og igangsæt på administrer adresser

Account Roles

En konto-rolle angiver, hvad et medlem kan gøre på dine konti. Standardrollerne dækker alle nuværende og fremtidige konti, så et medlem med "Trade all" kan handle på en konto, du opretter i morgen.

Rolle

Hvad det giver til hver konto

Læs alt

Læs

Handl alt

Handl

Administrer alle midler

Overfør, hæv, tildel Earn, fjern tildeling af Earn

Fuld adgang

Alle kontotilladelser

Standardprofiler og -roller følger produktet: når en ny arbejdsgang tilføjes, får medlemmer, der har en af disse, automatisk det passende niveau. Se roller, profiler og tilladelser for den komplette model.

Hvis et medlems tilladelser ikke stemmer overens med en standardprofil, placeres de på en rolle, der indeholder præcis det, de havde. Medlemmer med identiske tilladelser deler én rolle, så din organisation vil have langt færre roller end medlemmer.

Disse roller får deres navn fra den etiket, du havde skrevet ved siden af medlemmet, så et medlem mærket „Trader“ får en rolle kaldet trader. Medlemmer uden etiket får rollen migrated-role. Hver rolle bærer et migreret-mærke, hvilket betyder, at navnet blev genereret og kan ændres af dig.

Tip:

Omdøbning af disse roller, så de stemmer overens med det, du faktisk kalder disse personer, er den bedste første opgave efter konverteringen. Redigering af en rolle fjerner det migrerede mærke.

Hvorfor dine „Admin“-medlemmer ikke er på Admin-profilen

Beta-etiketten „Admin“ tillod nogen at se, igangsætte og godkende, men ikke fuldføre deres egne anmodninger uden en anden godkendelse. Admin-profilen inkluderer dog denne mulighed, som er Execute-niveauet.

I stedet for at give det automatisk, placeres medlemmer med den gamle etiket på en rolle kaldet beta-admin, der indeholder præcis de tilladelser, de allerede havde. Det er en enkelt tildeling at flytte dem til Admin, når du beslutter dig for det.

Bemærk:

beta-admin er en af dine egne roller, så medlemmer, der har den, vil ikke automatisk få nye arbejdsgange, som standardprofilerne gør. Dette er en yderligere grund til at gennemgå disse roller kort efter konverteringen.

Ejeren placeres på Admin-profilen, beholder alt, hvad de havde, og får automatisk nye arbejdsgange. Ejeren har også Læs alt-tilladelse, som ikke kan fjernes.

Hvis du bevidst havde reduceret ejerens tilladelser, bevares denne beslutning: Ejeren konverteres til en rolle, der indeholder deres faktiske tilladelser, ligesom ethvert andet medlem.

  • Hver tilladelse, som hvert medlem havde, overføres.
  • API-nøglelegitimationsoplysninger, tilladelser og kontokortlægning bevares.
  • Balancer, konti og kontoejerskab forbliver uberørte.
  • Godkendelsesanmodninger, der allerede er i gang, fortsætter, og dine politikker, godkendelsestærskler og indstillinger for „altid kræv godkendelse“ er uændrede.
  • Identitetsbekræftelse påvirkes ikke, og ingen behøver at logge ind igen eller blive geninviteret.
  • Kun konti, der tilhører din organisation, konverteres. En tilladelse på enhver konto uden for den forbliver, som den er.

Fejlfinding

Anmodningen mangler næsten helt sikkert account_id. Uden den løses et privat kald ikke til en af nøglens konti og kan svare med et tomt resultat i stedet for en fejl. Tilføj account_id til URL'en, og tjek hvert endpoint, din integration kalder, ikke kun dem, der synligt fejlede. Se API-nøgler.

Kaldet oprettede en anmodning og låste beløbet på kildekontoen. Afvikling følger godkendelse. Spor anmodningen med det approval_request_id, der returneres af kaldet, eller find det på siden Anmodninger. Se Overførsler og udbetalinger.

Medlemmer, hvis tilladelser ikke matchede en standardprofil, har hver især brug for en rolle, der bevarer deres adgang, og to medlemmer flettes kun til én rolle, når deres tilladelser er identiske. Medlemmer, du havde givet forskellige mærkater, forbliver i separate roller, selvom deres tilladelser stemmer overens, fordi mærkaterne antyder, at forskellen var tilsigtet. Roller, du ikke har brug for, kan konsolideres ved at omfordele deres medlemmer og slette den tomme rolle.

Medlemmer, der administrerer Organization, f.eks. teamadgang, konti eller API-nøgler, placeres under Læs alle, da administration af en konto indebærer, at man kan se den. Hvis det er bredere, end du ønsker, skal du erstatte Læs alle med en Kontorolle, der er afgrænset til de specifikke konti, de har brug for.

Nej. Konverteringen er envejs. Alt, hvad den producerer, kan redigeres bagefter, så enhver adgangsordning, du havde, kan genopbygges ved hjælp af profiler og roller.

Relaterede artikler

Har du brug for mere hjælp?