Umstellung von Beta

Dieser Artikel richtet sich an Organisationen, die unter dem Beta-Zugangsmodell erstellt wurden, bei dem ein Administrator jedem Mitglied einzeln Berechtigungen erteilt hat. Der Zugriff wird nun aus Workflow-Profilen und Kontorollen aufgebaut, und Kraken konvertiert Ihre Organisation für Sie.

Zwei Dinge benötigen Ihre Aufmerksamkeit vor der Konvertierung:

  • Wenn Sie API-Schlüssel verwenden, müssen Ihre Integrationen zuerst aktualisiert werden. Die Art und Weise, wie Anfragen ein Konto auswählen, hat sich geändert, und ein erfolgreicher Auszahlungsaufruf bedeutet nicht mehr, dass die Gelder verschoben wurden. Siehe „Aktualisieren Sie Ihre API-Integrationen“ unten.
  • Wir werden Sie bitten, zu bestätigen, dass Sie bereit sind. Ihre Organisation wird erst konvertiert, wenn Sie die Änderung akzeptieren.

Nichts in der Konvertierung entfernt den Zugriff. Jede Berechtigung, die jedes Mitglied hatte, wird übernommen.

Ihre bestehenden API-Schlüssel werden nicht widerrufen oder neu ausgestellt. Ihre Zugangsdaten, Berechtigungen und Kontozuordnung werden alle übernommen. Was sich ändert, ist, wie Ihr Code Anfragen adressiert und Antworten liest.

Wählen Sie bei jeder Anfrage ein Konto aus

Ein Organisations-API-Schlüssel deckt ein oder mehrere Konten ab und hat keine Standardeinstellung, daher muss jede private Anfrage angeben, für welches Konto sie gilt. Übergeben Sie account_id als Abfrageparameter in der URL, nicht im Anfragetext:

bash

Bash

POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYH

Dies gilt gleichermaßen für den Handel, Bilanz- und Hauptbuchabfragen, Order- und Transaktionshistorie, Exporte und Geldbewegungen.

Vorsicht:

Lesen Sie die neue Auszahlungsantwort

WithdrawFunds gibt approval_request_id zusammen mit refid zurück:

bash

Bash

{
  "error": [],
  "result": {
    "refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
    "approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
  }
}
  • Ein refid bedeutet nicht mehr, dass die Auszahlung abgeschlossen ist. Der Betrag wird auf dem Quellkonto gesperrt, wenn die Anfrage übermittelt wird, und er wird erst nach Genehmigung der Anfrage abgerechnet.
  • approval_request_id ist das Handle für die Genehmigung, auf die die Auszahlung wartet. Speichern Sie es in Ihren eigenen Unterlagen.
  • Auszahlungen, die auf Genehmigung warten, erscheinen nicht in WithdrawStatus. Eine Anfrage, die abgelehnt wird oder abläuft, erstellt überhaupt keinen Auszahlungsdatensatz, daher bedeutet das Fehlen in WithdrawStatus niemals, dass eine Auszahlung nicht übermittelt wurde.

Automatisierung, die ein refid als Nachweis des Abschlusses behandelt, wird Auszahlungen als abgerechnet melden, während sie sich noch in der Genehmigungswarteschlange befinden. Siehe API-Schlüssel für das vollständige Modell.

Ihre Organisation geht aus der Konvertierung mit zwei Sätzen standardmäßiger Bausteine hervor.

Workflow-Profile

Ein Workflow-Profil legt fest, was ein Mitglied bei jedem gesteuerten Workflow tun kann. Jedes Mitglied besitzt genau eines.

Profil

Was es enthält

Admin

Jede Ebene in jedem Workflow, einschließlich Execute

Initiator

Anzeigen und Initiieren bei jedem Workflow. Kann nicht genehmigen

Genehmiger

Anzeigen und Genehmigen bei jedem Workflow. Kann nicht initiieren

Auditor

Anzeigen bei jedem Workflow. Kann nicht agieren

Fondsmanager

Anzeigen, Initiieren und Genehmigen bei Auszahlungsanfrage und Übertragungsanfrage. Anzeigen und Initiieren bei Adressen verwalten

Kontorollen

Eine Kontorolle legt fest, was ein Mitglied auf Ihren Konten tun kann. Die Standardrollen decken alle aktuellen und zukünftigen Konten ab, sodass ein Mitglied mit Trade all auf einem Konto handeln kann, das Sie morgen erstellen.

Rolle

Was es für jedes Konto gewährt

Read all

Read

Trade all

Trade

Funds all

Transfer, Withdraw, Earn Allocate, Earn Deallocate

Voller Zugriff

Jede Kontoberechtigung

Standardprofile und Rollen entwickeln sich mit dem Produkt weiter: Wenn ein neuer Workflow hinzugefügt wird, erhalten Mitglieder, die ein solches innehaben, automatisch die entsprechende Stufe. Eine vollständige Beschreibung finden Sie unter Rollen, Profile und Berechtigungen.

Wenn die Berechtigungen eines Mitglieds keinem Standardprofil entsprechen, werden sie einer Rolle zugewiesen, die genau die Berechtigungen enthält, die sie zuvor hatten. Mitglieder mit identischen Berechtigungen teilen sich eine einzige Rolle, sodass Ihre Organisation weitaus weniger Rollen als Mitglieder haben wird.

Diese Rollen erhalten ihren Namen von der Bezeichnung, die Sie neben dem Mitglied vermerkt hatten, sodass ein als „Trader“ bezeichnetes Mitglied einer Rolle namens trader zugewiesen wird. Mitglieder ohne Bezeichnung erhalten migrated-role. Jede davon trägt ein migrated-Badge, was bedeutet, dass der Name generiert wurde und von Ihnen geändert werden kann.

Tipp:

Diese Rollen umzubenennen, um sie an die tatsächliche Bezeichnung dieser Personen anzupassen, ist die beste erste Aufgabe nach der Umstellung. Das Bearbeiten einer Rolle entfernt das migrated-Badge.

Warum Ihre „Admin“-Mitglieder nicht im Admin-Profil sind

Die Beta-Bezeichnung „Admin“ ermöglichte es jemandem, Anfragen anzuzeigen, zu initiieren und zu genehmigen, aber nicht, diese ohne zweite Genehmigung selbst abzuschließen. Das Admin-Profil beinhaltet diese Möglichkeit, die der Execute-Stufe entspricht.

Anstatt sie automatisch zu gewähren, werden Mitglieder mit der alten Bezeichnung einer Rolle namens beta-admin zugewiesen, die genau die Berechtigungen enthält, die sie bereits hatten. Das Verschieben dieser Mitglieder zu Admin ist eine einmalige Zuweisung, wann immer Sie sich dazu entschließen.

Hinweis:

beta-admin ist eine Ihrer eigenen Rollen, sodass Mitglieder, die sie innehaben, neue Workflows nicht automatisch übernehmen, wie es bei Standardprofilen der Fall ist. Dies ist ein weiterer Grund, diese Rollen bald nach der Umstellung zu überprüfen.

Der Owner wird dem Admin-Profil zugewiesen, behält alles, was er hatte, und übernimmt neue Workflows automatisch. Der Owner besitzt auch Read all, was nicht entfernt werden kann.

Wenn Sie die Berechtigungen des Owners bewusst reduziert hatten, bleibt diese Entscheidung erhalten: Der Owner wird in eine Rolle umgewandelt, die seine tatsächlichen Berechtigungen enthält, wie jedes andere Mitglied.

  • Jede Berechtigung, die jedes Mitglied hatte, wird übernommen.
  • API-Schlüssel-Zugangsdaten, Berechtigungen und Kontozuordnungen bleiben erhalten.
  • Salden, Konten und Kontoinhaberschaft bleiben unberührt.
  • Laufende Genehmigungsanfragen werden fortgesetzt, und Ihre Richtlinien, Genehmigungsschwellenwerte und Einstellungen für „immer Genehmigung erforderlich“ bleiben unverändert.
  • Die Identitätsprüfung bleibt unberührt, und niemand muss sich erneut anmelden oder wieder eingeladen werden.
  • Nur Konten, die zu Ihrer Organisation gehören, werden umgewandelt. Eine Berechtigung für ein Konto außerhalb davon bleibt unverändert.

Fehlerbehebung

Der Anfrage fehlt mit ziemlicher Sicherheit die account_id. Ohne diese wird ein privater Aufruf keinem der Konten des Schlüssels zugeordnet und kann ein leeres Ergebnis anstelle eines Fehlers zurückgeben. Fügen Sie die account_id zur URL hinzu und überprüfen Sie jeden Endpunkt, den Ihre Integration aufruft, nicht nur die, die sichtbar fehlgeschlagen sind. Siehe API-Schlüssel.

Der Aufruf hat eine Anfrage erstellt und den Betrag auf dem Quellkonto gesperrt. Die Abrechnung erfolgt nach Genehmigung. Verfolgen Sie die Anfrage mit der vom Aufruf zurückgegebenen approval_request_id oder finden Sie sie auf der Seite „Anfragen“. Siehe Überweisungen und Abhebungen.

Mitglieder, deren Berechtigungen keinem Standardprofil entsprachen, benötigen jeweils eine Rolle, die ihren Zugriff bewahrt. Zwei Mitglieder werden nur dann zu einer Rolle zusammengeführt, wenn ihre Berechtigungen identisch sind. Mitglieder, denen Sie unterschiedliche Bezeichnungen zugewiesen hatten, bleiben auf separaten Rollen, selbst wenn ihre Berechtigungen übereinstimmen, da die Bezeichnungen darauf hindeuten, dass die Unterscheidung beabsichtigt war. Nicht benötigte Rollen können konsolidiert werden, indem Sie ihre Mitglieder neu zuweisen und die leere Rolle löschen.

Mitglieder, die die Organisation verwalten, z. B. den Teamzugriff, Konten oder API-Schlüssel, werden in „Alle lesen“ platziert, da die Verwaltung eines Kontos impliziert, es sehen zu können. Wenn dies umfassender ist, als Sie möchten, ersetzen Sie „Alle lesen“ durch eine Konto-Rolle, die auf die spezifischen Konten zugeschnitten ist, die sie benötigen.

Nein. Die Umstellung ist eine Einbahnstraße. Alles, was sie erzeugt, ist anschließend bearbeitbar, sodass jede Zugriffsvereinbarung, die Sie hatten, mithilfe von Profilen und Rollen wiederhergestellt werden kann.

Brauchst du Hilfe?