Övergång från beta

Denna artikel vänder sig till organisationer som skapats under betaåtkomstmodellen, där en administratör tilldelade behörigheter till varje medlem individuellt. Åtkomst byggs nu av arbetsflödesprofiler och kontoroller, och Kraken konverterar din organisation åt dig.

Två saker kräver din uppmärksamhet före konverteringen:

  • Om du använder API-nycklar måste dina integrationer uppdateras först. Sättet på vilket förfrågningar väljer ett konto har ändrats, och ett framgångsrikt uttagsanrop innebär inte längre att medlen har flyttats. Se ”Uppdatera dina API-integrationer” nedan.
  • Vi kommer att be dig bekräfta att du är redo. Din organisation konverteras inte förrän du har godkänt ändringen.

Ingenting i konverteringen tar bort åtkomst. Varje behörighet som varje medlem hade förs över.

Dina befintliga API-nycklar återkallas eller utfärdas inte på nytt. Deras inloggningsuppgifter, behörigheter och kontomappning förs alla över. Det som ändras är hur din kod adresserar förfrågningar och läser svar.

Välj ett konto för varje förfrågan

En API-nyckel för organisationen omfattar ett eller flera konton och har inget standardval, så varje privat förfrågan måste ange vilket konto den gäller. Skicka account_id som en frågeparameter i URL:en, inte i förfrågan-kroppen:

bash

Bash

POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYH

Detta gäller för handel, saldoförfrågningar och huvudboksfrågor, order- och handelshistorik, exporter samt kapitalförflyttningar.

Varning:

Testa varje anropssökväg i en icke-produktionsmiljö innan du byter, inklusive de som du inte förväntar dig har ändrats. En privat förfrågan som utelämnar account_id kan returnera ett framgångsrikt men tomt resultat snarare än ett fel, vilket lätt kan misstolkas som ett konto utan aktivitet.

Läs det nya uttagssvaret

WithdrawFunds returnerar approval_request_id tillsammans med refid:

bash

Bash

{
  "error": [],
  "result": {
    "refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
    "approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
  }
}
  • Ett refid innebär inte längre att uttaget är slutfört. Beloppet låses på källkontot när förfrågan skickas in, och det avvecklas först efter att förfrågan har godkänts.
  • approval_request_id är handtaget för det godkännande som uttaget väntar på. Spara det i din egen dokumentation.
  • Uttag som väntar på godkännande visas inte i WithdrawStatus. En förfrågan som avvisas eller löper ut skapar ingen uttagsregistrering alls, så frånvaro från WithdrawStatus betyder aldrig att ett uttag inte skickades in.

Automatisering som behandlar ett refid som bevis på slutförande kommer att rapportera uttag som avvecklade medan de fortfarande ligger i godkännandekön. Se API-nycklar för hela modellen.

Din organisation kommer ur konverteringen med två uppsättningar standardbyggstenar.

Arbetsflödesprofiler

En arbetsflödesprofil fastställer vad en medlem kan göra i varje styrt arbetsflöde. Varje medlem har exakt en.

Profil

Vad den innehåller

Administratör

Varje nivå i varje arbetsflöde, inklusive Utför

Initiativtagare

Visa och initiera i varje arbetsflöde. Kan inte godkänna

Godkännare

Visa och godkänn i varje arbetsflöde. Kan inte initiera

Revisor

Visa i varje arbetsflöde. Kan inte utföra handlingar

Kapitalförvaltare

Visa, initiera och godkänn för uttagsförfrågan och överföringsförfrågan. Visa och initiera för Hantera adresser

Kontoroller

En kontoroll fastställer vad en medlem kan göra på dina konton. Standardrollerna täcker alla nuvarande och framtida konton, så en medlem med rollen ”Handla allt” kan handla på ett konto som du skapar imorgon.

Roll

Vad den ger för varje konto

Läs alla

Läs

Handla alla

Handla

Medel alla

Överföring, uttag, Earn-allokering, Earn-avallokering

Full åtkomst

Varje kontobehörighet

Standardprofiler och roller följer med produkten: när ett nytt arbetsflöde läggs till får medlemmar som innehar en sådan automatiskt rätt nivå. Se Roller, profiler och behörigheter för den fullständiga modellen.

Där en medlems behörigheter inte matchar någon standardprofil placeras de i en roll som omfattar exakt det de hade. Medlemmar med identiska behörigheter delar en enda roll, så din organisation kommer att ha betydligt färre roller än medlemmar.

Dessa roller får sitt namn från den etikett du hade skrivit bredvid medlemmen, så en medlem som märkts som ”Trader” hamnar i en roll som heter trader. Medlemmar utan etikett hamnar i migrated-role. Varje roll har ett migrerat-märke, vilket innebär att namnet genererades och att du kan ändra det.

Tips:

Att döpa om dessa roller så att de matchar vad du faktiskt kallar dessa personer är den bästa första uppgiften efter konverteringen. Att redigera en roll tar bort migrerat-märket.

Varför dina ”Admin”-medlemmar inte finns i Admin-profilen

Beta-etiketten ”Admin” lät någon visa, initiera och godkänna, men inte slutföra sina egna förfrågningar utan ett andra godkännande. Admin-profilen inkluderar den möjligheten, vilket är Execute-nivån.

Istället för att bevilja den automatiskt placeras medlemmar med den gamla etiketten i en roll som heter beta-admin som har exakt de behörigheter de redan hade. Att flytta dem till Admin är en enkel tilldelning när du än bestämmer dig för det.

Obs:

beta-admin är en av dina egna roller, så medlemmar som innehar den kommer inte automatiskt att få nya arbetsflöden på samma sätt som standardprofilerna gör. Detta är ytterligare en anledning att se över dessa roller strax efter konverteringen.

Ägaren placeras i Admin-profilen, behåller allt de hade och får nya arbetsflöden automatiskt. Ägaren har även Läs alla, som inte kan tas bort.

Om du medvetet hade begränsat ägarens behörigheter bevaras det beslutet: ägaren konverteras till en roll som har deras faktiska behörigheter, precis som alla andra medlemmar.

  • Varje behörighet som varje medlem hade följer med.
  • API-nyckeluppgifter, behörigheter och kontomappning bevaras.
  • Saldon, konton och kontoägarskap förblir oförändrade.
  • Godkännandeförfrågningar som redan pågår fortsätter, och dina policyer, godkännandetrösklar och inställningar för ”kräv alltid godkännande” är oförändrade.
  • Identitetsverifiering påverkas inte, och ingen behöver logga in igen eller bjudas in på nytt.
  • Endast konton som tillhör din organisation konverteras. En behörighet på något konto utanför den lämnas som den är.

Felsökning

Förfrågan saknar nästan säkert account_id. Utan detta kan ett privat anrop inte kopplas till något av nyckelns konton och kan svara med ett tomt resultat istället för ett felmeddelande. Lägg till account_id i URL:en och kontrollera varje endpoint som din integration anropar, inte bara de som uppenbarligen misslyckades. Se API-nycklar.

Anropet skapade en förfrågan och låste beloppet på källkontot. Avräkning sker efter godkännande. Följ förfrågan med det approval_request_id som returneras av anropet, eller hitta det på sidan Requests. Se Överföringar och uttag.

Medlemmar vars behörigheter inte matchade en standardprofil behöver var och en en roll som bevarar deras åtkomst, och två medlemmar slås endast ihop till en roll när deras behörigheter är identiska. Medlemmar som du har gett olika etiketter stannar kvar på separata roller även när deras behörigheter matchar, eftersom etiketterna antyder att distinktionen var avsiktlig. Roller du inte behöver kan konsolideras genom att omplacera deras medlemmar och radera den tomma rollen.

Medlemmar som administrerar organisationen, hanterar teamåtkomst, konton eller API-nycklar, placeras i Read all, eftersom administrering av ett konto innebär att man kan se det. Om detta är bredare än du vill, ersätt Read all med en kontoroll som är begränsad till de specifika konton de behöver.

Nej. Konverteringen är enkelriktad. Allt den skapar är redigerbart i efterhand, så alla åtkomstupplägg du hade kan återskapas med hjälp av profiler och roller.

Relaterade artiklar

Behöver du mer hjälp?