Wechsel aus der Beta

Deine vorhandenen API-Schlüssel werden weder widerrufen noch neu ausgestellt. Anmeldedaten, Berechtigungen und Kontomapping werden vollständig übernommen. Bestehende Aufrufe, die keine account_id übergeben, werden weiterhin über das primäre Konto der Organisation abgewickelt. Prüfe, wie deine Integration ein anderes Konto auswählt und Auszahlungsantworten auswertet.

Bei Bedarf ein bestimmtes Konto wählen

Wird account_id weggelassen, wird eine private Anfrage über das primäre Konto ausgeführt:

Um einen Vorgang auf einem bestimmten Konto auszuführen, übergib account_id als Query-Parameter in der URL:

Übergib den Parameter in der URL, nicht im Request-Body. Eine explizit angegebene account_id hat Vorrang vor dem Fallback auf das primäre Konto. Das Kontomapping und die Berechtigungen des Schlüssels werden dadurch nicht erweitert.

Neue Auszahlungsantwort lesen

WithdrawFunds gibt approval_request_id zusammen mit refid zurück:

• Eine refid bedeutet nicht mehr, dass die Auszahlung abgeschlossen wurde. Der Betrag wird auf dem Quellkonto gesperrt, sobald die Anfrage gestellt wird, und wird erst nach deren Genehmigung geschlossen.
• approval_request_id ist der Bezeichner für die Genehmigung, auf die die Auszahlung wartet. Hinterlege sie in deinen eigenen Aufzeichnungen.
• Auszahlungen, die auf Genehmigung warten, erscheinen nicht in WithdrawStatus. Eine abgelehnte oder ausgelaufene Anfrage erzeugt keinen Auszahlungsdatensatz, daher bedeutet das Fehlen in WithdrawStatus niemals, dass eine Auszahlung nicht eingereicht wurde.

Automatisierungen, die eine refid als Abschlussbestätigung behandeln, melden Auszahlungen als geschlossen, während diese noch in der Genehmigungswarteschlange liegen. Das vollständige Modell findest du unter API-Schlüssel.

Nach der Konvertierung stehen deiner Organisation zwei Arten standardisierter Bausteine zur Verfügung.

Workflow Profiles

Ein Workflow Profile legt fest, was ein Mitglied in jedem verwalteten Workflow tun kann. Jedes Mitglied hat genau eines.

Account Roles

Eine Account Role legt fest, was ein Mitglied auf deinen Konten tun kann. Die Standardrollen gelten für alle aktuellen und künftigen Konten – ein Mitglied mit der Rolle „Trade all" kann also auch auf einem Konto traden, das du erst morgen anlegst.

Standardprofile und -rollen wachsen mit dem Produkt mit: Wird ein neuer Workflow hinzugefügt, erhalten Mitglieder mit einem Standardprofil oder einer Standardrolle automatisch die passende Berechtigungsstufe. Das vollständige Modell findest du unter Rollen, Profile und Berechtigungen.

Stimmen die Berechtigungen eines Mitglieds mit keinem Standardprofil überein, wird es einer Rolle zugewiesen, die genau die bisherigen Berechtigungen enthält. Mitglieder mit identischen Berechtigungen teilen sich eine Rolle – deine Organisation hat dadurch deutlich weniger Rollen als Mitglieder.

Diese Rollen übernehmen die Bezeichnung, die du neben dem Mitglied eingetragen hattest – ein Mitglied mit dem Label „Trader" landet in einer Rolle namens trader. Mitglieder ohne Label werden der Rolle migrated-role zugewiesen. Jede solche Rolle trägt ein migrated-Abzeichen – der Name wurde automatisch vergeben und kann jederzeit geändert werden.

Warum deine „Admin"-Mitglieder nicht dem Admin-Profil zugewiesen sind

Das Beta-Label „Admin" ermöglichte es, Anfragen einzusehen, einzuleiten und zu genehmigen – aber nicht, eigene Anfragen ohne eine zweite Genehmigung abzuschließen. Das Admin-Profil umfasst genau diese Fähigkeit: die Execute-Stufe.

Statt diese Berechtigung automatisch zu vergeben, werden Mitglieder mit dem alten Label einer Rolle namens beta-admin zugewiesen, die genau die bisherigen Berechtigungen enthält. Die Zuweisung zum Admin-Profil ist jederzeit mit einer einzigen Aktion möglich.

Der Inhaber wird dem Admin-Profil zugewiesen, behält alle bisherigen Berechtigungen und übernimmt neue Workflows automatisch. Der Inhaber hat außerdem die Rolle „Alles lesen", die nicht entfernt werden kann.

Hast du die Berechtigungen des Inhabers zuvor bewusst eingeschränkt, bleibt diese Entscheidung erhalten: Der Inhaber wird in eine Rolle mit genau seinen tatsächlichen Berechtigungen konvertiert – wie jedes andere Mitglied.

• Alle Berechtigungen jedes Mitglieds werden vollständig übernommen.
• Anmeldedaten, Berechtigungen und Kontozuordnungen der API-Schlüssel bleiben erhalten.
• Guthaben, Konten und Kontoinhaber bleiben unverändert.
• Laufende Genehmigungsanfragen werden fortgeführt; deine Richtlinien, Genehmigungsschwellenwerte und die Einstellung „Genehmigung immer erforderlich" bleiben unverändert.
• Die Identitätsverifizierung ist nicht betroffen; niemand muss sich erneut anmelden oder neu eingeladen werden.
• Nur Konten, die zu deiner Organisation gehören, werden konvertiert. Berechtigungen für Konten außerhalb der Organisation bleiben unverändert.

Aufrufe ohne account_id verwenden das primäre Konto der Organisation. Um Berichte für ein anderes Konto aus der Kontozuordnung des Schlüssels abzurufen, übergib die account_id dieses Kontos als URL-Parameter. Siehe „Bestimmtes Konto bei Bedarf auswählen".

Der Aufruf hat eine Anfrage erstellt und den Betrag auf dem Quellkonto gesperrt. Die Abrechnung erfolgt nach der Genehmigung. Verfolge die Anfrage anhand der vom Aufruf zurückgegebenen approval_request_id oder suche sie auf der Seite „Anfragen". Siehe Überweisungen und Auszahlungen.

Mitglieder, deren Berechtigungen keinem Standardprofil entsprechen, erhalten jeweils eine eigene Rolle, die ihren Zugriff erhält. Zwei Mitglieder werden nur dann auf eine gemeinsame Rolle zusammengeführt, wenn ihre Berechtigungen identisch sind. Mitglieder, denen du unterschiedliche Bezeichnungen gegeben hast, bleiben auf getrennten Rollen, auch wenn ihre Berechtigungen übereinstimmen – denn die Bezeichnungen deuten darauf hin, dass die Unterscheidung beabsichtigt war. Nicht benötigte Rollen lassen sich konsolidieren, indem du ihre Mitglieder neu zuweist und die leere Rolle löschst.

Mitglieder, die die Organisation verwalten – also Teamzugriff, Konten oder API-Schlüssel administrieren – werden in „Read all" eingestuft, da die Verwaltung eines Kontos voraussetzt, dass man es einsehen kann. Falls das weiter gefasst ist als gewünscht, ersetze „Read all" durch eine Kontorolle, die nur die Konten umfasst, die die jeweiligen Mitglieder benötigen.

Nein. Die Konvertierung ist ein nicht umkehrbarer Vorgang. Alles, was dabei entsteht, lässt sich im Nachhinein bearbeiten – jede Zugriffsstruktur, die du vorher hattest, kann mithilfe von Profilen und Rollen neu aufgebaut werden.