Siirtyminen Beta-versiosta

Viimeksi päivitetty: 20. elokuuta 2026

Tämä artikkeli on tarkoitettu organisaatioille, jotka on luotu Beta-käyttöoikeusmallin mukaisesti, jossa järjestelmänvalvoja myönsi käyttöoikeudet jokaiselle jäsenelle erikseen. Käyttöoikeudet perustuvat nyt työnkulkuprofiileihin ja tilirooleihin, ja Kraken muuntaa organisaatiosi puolestasi.

Ennen muuntoa on kaksi asiaa, joihin sinun tulee kiinnittää huomiota:

  • Jos käytät API-avaimia, tarkista niiden toiminta organisaatiossasi. Olemassa olevat kutsut jatkuvat ensisijaisella tilillä. Valitse toinen tili account_id:llä ja käsittele onnistunutta nostovastausta pyyntönä – ei todisteena siitä, että varat ovat siirtyneet. Katso alta kohta "Tarkista API-toimintasi".
  • Pyydämme sinua vahvistamaan, että olet valmis. Organisaatiosi muunnetaan vasta, kun hyväksyt muutoksen.

Muunto ei poista mitään käyttöoikeuksia. Jokaisen jäsenen kaikki käyttöoikeudet säilyvät.

Olemassa olevia API-avaimia ei peruuteta eikä uusita. Niiden tunnistetiedot, käyttöoikeudet ja tilimääritykset säilyvät kaikki ennallaan. Olemassa olevat kutsut, jotka eivät välitä account_id:tä, jatkuvat organisaation ensisijaisella tilillä. Tarkista, miten integraatiosi valitsee toisen tilin ja lukee nostovastaukset.

Valitse tarvittaessa tietty tili

Kun account_id jätetään pois, yksityinen pyyntö toimii ensisijaisella tilillä:

bash

Bash

POST /0/private/AddOrder

Toimiaksesi tietyllä tilillä, välitä account_id URL-osoitteen kyselyparametrina:

bash

Bash

POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYH

Välitä se URL-osoitteessa, ei pyyntörungossa. Nimenomainen account_id ohittaa ensisijaisen tilin oletusarvon. Se ei laajenna avaimen tilimääritystä tai käyttöoikeuksia.

Lue uusi noston vastaus

WithdrawFunds palauttaa approval_request_id:n sekä refid:n:

bash

Bash

{
  "error": [],
  "result": {
    "refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
    "approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
  }
}
  • Refid ei enää tarkoita, että nosto on suoritettu. Summa lukitaan lähdetililtä pyynnön lähettämishetkellä, ja se selvitetään vasta pyynnön hyväksymisen jälkeen.
  • approval_request_id on hyväksynnän käsittelytunniste, jota nosto odottaa. Tallenna se omaan tietueeseen.
  • Hyväksyntää odottavat nostot eivät näy WithdrawStatus-vastauksessa. Hylätty tai vanhentunut pyyntö ei luo nostokirjausta lainkaan, joten puuttuminen WithdrawStatus-vastauksesta ei tarkoita, että nostoa ei olisi lähetetty.

Automaatio, joka tulkitsee refid-arvon suorituksen todisteeksi, raportoi nostot selvitetyiksi, vaikka ne odottavat edelleen hyväksyntää. Katso koko malli kohdasta API-avaimet.

Muunnon jälkeen organisaatiollasi on käytössä kaksi vakiokomponenttia.

Workflow Profiles

Workflow Profile määrittää, mitä jäsen voi tehdä kullakin hallinnoidulla työnkululla. Jokaisella jäsenellä on täsmälleen yksi.

Profiili

Sisältö

Ylläpitäjä

Kaikki tasot kaikilla työnkuluilla, Execute mukaan lukien

Aloittaja

Näytä ja käynnistä kaikilla työnkuluilla. Ei voi hyväksyä

Hyväksyjä

Näytä ja hyväksy kaikilla työnkuluilla. Ei voi käynnistää

Tarkastaja

Näytä kaikilla työnkuluilla. Ei voi toimia

Varainhallitsija

Näytä, käynnistä ja hyväksy nostopyynnöissä ja siirtopyynnöissä. Näytä ja käynnistä osoitteiden hallinnassa

Tililoolit

Tilirooli määrittää, mitä jäsen voi tehdä organisaation tileillä. Vakioroolit kattavat kaikki nykyiset ja tulevat tilit, joten Trade all -roolilla oleva jäsen voi käydä kauppaa myös tilillä, jonka luot huomenna.

Rooli

Oikeudet kaikilla tileillä

Read all

Lue

Trade all

Käy kauppaa

Funds all

Siirto, nosto, Earn-allokointi, Earn-allokoinnin poisto

Täysi pääsy

Kaikki tilioikeudet

Vakioprofiilit ja -roolit pysyvät tuotteen mukana: kun uusi työnkulku lisätään, sitä käyttävät jäsenet saavat automaattisesti asianmukaisen tason. Lue lisää: Roolit, profiilit ja oikeudet.

Jos jäsenen oikeudet eivät vastaa yhtään vakioprofiilia, jäsen sijoitetaan rooliin, joka sisältää täsmälleen ne oikeudet, jotka hänellä oli. Jäsenet, joilla on samat oikeudet, jakavat yhden roolin, joten organisaatiossasi on huomattavasti vähemmän rooleja kuin jäseniä.

Roolit saavat nimensä jäsenen kohdalle kirjoittamastasi tunnisteesta, joten "Trader"-tunnisteella merkitty jäsen sijoitetaan rooliin nimeltä trader. Tunnisteettomat jäsenet sijoitetaan rooliin migrated-role. Jokaisessa tällaisessa roolissa on migrated-merkintä, joka tarkoittaa, että nimi on luotu automaattisesti ja sen voi vaihtaa.

Vinkki:

Nimeä roolit uudelleen vastaamaan todellisia tehtävänimikkeitä – se on paras ensimmäinen askel muunnon jälkeen. Roolin muokkaus poistaa migrated-merkinnän.

Miksi “Admin”-jäsenet eivät ole Admin-profiilissa

Beta-vaiheen “Admin”-tunniste salli tarkastella, käynnistää ja hyväksyä pyyntöjä, mutta ei suorittaa omia pyyntöjä loppuun ilman toista hyväksyntää. Admin-profiili sisältää tämän oikeuden (Execute-taso).

Oikeutta ei myönnetä automaattisesti. Sen sijaan vanhan tunnisteen omaavat jäsenet siirretään rooliin nimeltä beta-admin, joka sisältää täsmälleen heidän aiemmat oikeutensa. Voit siirtää heidät Admin-profiiliin yhdellä määrityksellä milloin tahansa.

Huomautus:

beta-admin on yksi omista rooleistasi, joten sitä pitävät jäsenet eivät automaattisesti saa uusia työnkulkuja käyttöönsä niin kuin vakioprofiilit tekevät. Tämä on lisäsyy tarkastella näitä rooleja pian muunnon jälkeen.

Omistaja sijoitetaan Admin-profiiliin, säilyttää kaikki aiemmat oikeutensa ja saa uudet työnkulut automaattisesti käyttöönsä. Omistajalla on myös Read all -rooli, jota ei voi poistaa.

Jos olet tahallisesti rajoittanut omistajan käyttöoikeuksia, päätös säilyy: omistaja muunnetaan rooliksi, joka sisältää hänen todelliset käyttöoikeutensa, kuten muidenkin jäsenten kohdalla.

  • Jokaisen jäsenen kaikki käyttöoikeudet säilyvät.
  • API-avainten tunnistetiedot, käyttöoikeudet ja tilikartoitus säilytetään.
  • Saldot, tilit ja tilien omistajuus pysyvät muuttumattomina.
  • Käsittelyssä olevat hyväksyntäpyynnöt jatkuvat, ja käytäntösi, hyväksyntärajasi sekä „vaadi aina hyväksyntä" -asetukset pysyvät ennallaan.
  • Henkilöllisyyden vahvistus ei muutu, eikä kenenkään tarvitse kirjautua sisään uudelleen tai hyväksyä uutta kutsua.
  • Vain organisaatiosi tilit muunnetaan. Käyttöoikeus millä tahansa sen ulkopuolisella tilillä jää ennalleen.

Vianmääritys

Kutsut, joissa ei ole account_id-parametria, kohdistuvat organisaation ensisijaiseen tiliin. Jos haluat raportoida toisesta tilistä avaimen tilikartoituksessa, välitä kyseisen tilin account_id URL-osoitteessa. Katso „Valitse tarvittaessa tietty tili."

Kutsu loi pyynnön ja lukitsi summan lähdetilille. Selvitys tapahtuu hyväksynnän jälkeen. Seuraa pyyntöä kutsun palauttamalla approval_request_id-tunnisteella tai etsi se Pyynnöt-sivulta. Katso Siirrot ja nostot.

Jäsenet, joiden käyttöoikeudet eivät vastaa standardiprofiilia, tarvitsevat kukin roolin, joka säilyttää heidän käyttöoikeutensa. Kaksi jäsentä yhdistetään samalle roolille vain, jos heidän käyttöoikeutensa ovat identtiset. Jäsenet, joille oli annettu eri nimiöt, pysyvät erillisillä rooleilla, vaikka heidän käyttöoikeutensa olisivat samat – nimiöt viittaavat siihen, että ero on ollut tarkoituksellinen. Tarpeettomat roolit voi yhdistää siirtämällä niiden jäsenet muualle ja poistamalla tyhjät roolit.

Organisaatiota hallinnoivat jäsenet – jotka hallitsevat tiimien käyttöoikeuksia, tilejä tai API-avaimia – sijoitetaan Lue kaikki -rooliin, koska tilin hallinnointi edellyttää sen näkemistä. Jos tämä on laajempi kuin haluat, korvaa Lue kaikki -rooli tilikohtaisella roolilla, joka on rajattu vain niihin tileihin, joihin he tarvitsevat pääsyn.

Ei. Muunto on yksisuuntainen. Muunnon kaikki tulokset ovat muokattavissa jälkikäteen, joten aiempi käyttöoikeusjärjestely voidaan rakentaa uudelleen profiileja ja rooleja käyttämällä.

Aiheeseen liittyvät artikkelit