All
Filtern nach:
Wie zahle ich Cash auf mein Konto ein?
Ich brauche Hilfe bei der Kontoverifizierung
Warum kann ich nicht auf mein Konto zugreifen?
Gibt es Gebühren für das Auszahlen von Krypto?
Ich brauche Hilfe bei der Anmeldung bei meinem Konto
API-Schlüssel ermöglichen automatisierten Systemen, Trading-Bots, Betriebsskripten, Reporting-Pipelines und FIX-Trading-Sessions programmatischen Zugriff auf die Konten deiner Organisation. Dieser Artikel beschreibt das Berechtigungsmodell für API-Schlüssel, die Zuordnung von Schlüsseln zu Konten, die Anwendung der Organisations-Governance auf schlüsselinitiierte Vorgänge sowie die Verwaltung von Schlüsseln selbst.
API-Schlüssel sind keine Mitglieder mit Anmeldedaten. Sie verwenden ein eigenes, einfacheres Berechtigungsmodell:
Mitglied | API-Schlüssel | |
|---|---|---|
Authentifizierung | Individuelle Anmeldung mit 2FA | API-Schlüssel-Anmeldedaten |
UI-Zugriff | Ja | Nein, nur API |
Berechtigungsmodell | Workflow-Profil + Kontorollen | API-Schlüsselberechtigungen gelten für alle ausgewählten Konten |
Kontospezifische Variation | Ja, Rollen können auf verschiedenen Konten unterschiedliche Berechtigungen vergeben | Nein, die Berechtigungen des Schlüssels gelten einheitlich für alle ausgewählten Konten |
Kann Auszahlungs- und Überweisungsanfragen stellen | Ja, wenn zulässig | Ja, wenn zulässig |
Kann Anfragen genehmigen | Ja, außer eigene | Niemals |
Administrative Workflows | Ja, gemäß Workflow-Profil | Niemals |
Die beiden Modelle sind bewusst voneinander getrennt. Mitglieder erhalten Rollen, Profile und kontospezifische Granularität, da Menschen unterschiedliche Verantwortungsbereiche ansammeln. Schlüssel nutzen ein flaches Berechtigungs-plus-Konten-Modell, da Automatisierung eng begrenzt, einheitlich und auf einen Blick prüfbar sein sollte.
Ein API-Schlüssel vereint zwei Festlegungen: was er darf (Berechtigungen) und wo (Konten).
Berechtigungen
Gruppieren | Berechtigung | Was sie erlaubt |
|---|---|---|
Mittel | Mittel abfragen | Guthaben und Finanzierungsstatus anzeigen |
Einzahlen | Einzahlungsadressen generieren und Einzahlungsverlauf anzeigen | |
Auszahlen | Auszahlungsanfragen stellen (siehe „Governance und API-Schlüssel") | |
Earn | Earn-Produkte zuteilen und Zuteilung aufheben | |
Orders | Offene Orders abfragen | Offene Orders und aktive Trades anzeigen |
Geschlossene Orders abfragen | Historische Orders und abgeschlossene Trades anzeigen | |
Orders erstellen und ändern | Orders aufgeben und ändern | |
Orders stornieren und schließen | Offene Orders stornieren und Positionen schließen | |
Adressen | Auszahlungsadresse hinzufügen | Anfragen zum Hinzufügen von Whitelist-Adressen stellen |
Auszahlungsadresse aktualisieren | Anfragen zur Änderung von Whitelist-Adressen stellen | |
Daten | Hauptbuch abfragen | Transaktions- und Hauptbuchverlauf anzeigen |
Daten exportieren | Kontodaten für Reporting und Abstimmung exportieren |
Kontozuordnung
Jeder Schlüssel wird bei der Erstellung einem oder mehreren Konten zugeordnet – diese Zuordnung kann später geändert werden. Die Berechtigungen des Schlüssels gelten einheitlich für alle ausgewählten Konten:
FIX-Konnektivität
Schlüssel mit Order-Berechtigungen unterstützen FIX-Konnektivität für Spot-Trading – ergänzend zur REST- und WebSocket-API. Eine FIX-Session übernimmt dieselben Berechtigungen und Kontozuordnungen wie der zugehörige Schlüssel: Sie tradet ausschließlich auf den ausgewählten Konten des Schlüssels, innerhalb seiner Berechtigungen. Unternehmen mit FIX-Order-Flow verwenden in der Regel einen dedizierten Schlüssel pro Session, der auf die Konten des jeweiligen Handelsbereichs beschränkt ist.
WebSocket-Trading auf anderen Konten als dem Hauptkonto ist für API-Schlüssel derzeit nicht verfügbar – diese Funktion ist vorerst ausschließlich Inhabern vorbehalten. Automatisierter Order-Flow auf zusätzlichen Konten sollte über REST oder FIX abgewickelt werden. Siehe Verfügbarkeit und Einschränkungen.
Sicherheitseinstellungen
Einstellung | Beschreibung |
|---|---|
Ablauf des Schlüssels | Optionales Ablaufdatum, nach dem der Schlüssel deaktiviert wird |
Startdatum / Enddatum der Abfrage | Datenanfragen auf einen bestimmten Zeitraum begrenzen |
WebSocket-Verbindungen | Echtzeit-Streaming aktivieren oder deaktivieren |
Benutzerdefiniertes Nonce-Fenster | Replay-Schutz für Hochfrequenznutzung anpassen |
IP-Einschränkungen | Schlüsselnutzung auf bestimmte IP-Adressen oder CIDR-Bereiche beschränken |
Weise jedem Schlüssel nur die minimal notwendigen Berechtigungen, so wenige Konten und so enge IP-Einschränkungen zu, wie seine Aufgabe erfordert. Verwende separate Schlüssel pro System – einen für den Trading-Bot, einen für das Reporting –, damit Sperrungen gezielt erfolgen.
Die Governance der Organisation regelt sowohl, was Schlüssel tun dürfen, als auch, wie sie verwaltet werden.
Was Schlüssel tun
Die Zwei-Kategorien-Regel für Members gilt für Schlüssel genauso:
Ein Schlüssel kann ausschließlich gesteuerte Anfragen initiieren. Schlüssel erhalten nie die Berechtigung „Genehmigen" – das Vier-Augen-Prinzip erfordert für jede Genehmigung einen menschlichen Member, und ein Skript kann dieses Urteilsvermögen nicht ersetzen. Wenn die Richtlinie für Auszahlungsanfragen zwei Genehmigungen verlangt, wartet eine schlüsselinitiierte Auszahlung auf zwei Members – genau wie eine member-initiierte.
Berücksichtige diese Asynchronität bei der Automatisierung: Ein erfolgreicher API-Aufruf bedeutet, dass die Anfrage erstellt wurde – nicht, dass Einlagen geflossen sind. Verfolge die Anfrage bis zum Abschluss und beachte die aktuelle Einschränkung: Eine ausstehende Anfrage reserviert keine Einlagen. Ändert sich das Guthaben während der Prüfung, schlägt die genehmigte Anfrage fehl und muss erneut gestellt werden. Siehe Einlagen bis zur Genehmigung verfügbar halten.
Schlüssel haben zudem keinen Zugriff auf administrative Workflows. Die Verwaltung von Teamzugängen, API-Schlüsseln, Konten, Adressen (über das Initiieren von Adressanfragen hinaus) und Richtlinien ist ausschließlich Members vorbehalten.
Wie Schlüssel verwaltet werden
Das Erstellen, Bearbeiten und Widerrufen von API-Schlüsseln ist eine gesteuerte Operation im dedizierten Workflow „API-Schlüssel verwalten" – getrennt vom Workflow „Team & Zugang verwalten". Diese Trennung ist aus zwei Gründen wichtig:
Das Secret des Schlüssels wird einmalig bei der Erstellung angezeigt. Speichere es sicher, bevor du die Seite verlässt – es kann später nicht mehr abgerufen werden.
Das Bearbeiten von Berechtigungen oder Konten eines Schlüssels sowie das Widerrufen eines Schlüssels folgen demselben geregelten Prozess.
Der API-Aufruf hat eine Auszahlungsanfrage erstellt, die gemäß der Richtlinie für Auszahlungsanfragen auf Genehmigung wartet. Sieh dir die Seite „Anfragen" an – die Anfrage erscheint dort mit dem Schlüssel als Initiator und wartet auf die erforderlichen Genehmigungen der Mitglieder. Das ist das Governance-Modell, wie es vorgesehen ist: Automatisierung initiiert, Menschen genehmigen.
Wenn die Anfrage genehmigt wurde und die Einlagen trotzdem nicht abgegangen sind, prüfe, ob das Quellguthaben zum Abschlusszeitpunkt ausreichte – eine ausstehende Anfrage reserviert keine Einlagen, sodass Kontobewegungen während der Prüfung dazu führen können, dass eine genehmigte Anfrage fehlschlägt. Reiche die Anfrage erneut ein, sobald das Guthaben wieder verfügbar ist.
Das betroffene Konto ist nicht im Konto-Mapping des Schlüssels enthalten. Ein Schlüssel greift ausschließlich auf seine zugewiesenen Konten zu. Bearbeite den Schlüssel, um das Konto hinzuzufügen – beachte, dass dort alle Berechtigungen des Schlüssels gelten, da Schlüssel keine kontospezifischen Unterschiede unterstützen. Wenn das zu weitreichend ist, erstelle einen zweiten Schlüssel, der auf das neue Konto beschränkt ist.
Ein einzelner Schlüssel kann die Berechtigungen nicht pro Konto variieren. Erstelle zwei Schlüssel: einen Trading-Schlüssel, der Konto A zugeordnet ist, und einen Nur-Lese-Schlüssel für Konto B. Schlüssel mit engerem Berechtigungsumfang lassen sich außerdem leichter prüfen und sicherer widerrufen.
Der Workflow „API-Schlüssel verwalten" erfordert wahrscheinlich eine Genehmigung – die Anfrage ist noch ausstehend. Der Schlüssel wird erst ausgestellt und sein Secret angezeigt, wenn alle erforderlichen Genehmigungen vorliegen. Den Status der Anfrage kannst du auf der Seite „Anfragen" prüfen.
Nein. Eine Genehmigung erfordert immer ein menschliches Mitglied der Organisation. Dies ist eine Systemregel, keine konfigurierbare Richtlinie – sie stellt sicher, dass die Mehrparteien-Genehmigung sinnvoll bleibt, wenn Automatisierung Kapitalbewegungen auslöst.