API-Schlüssel

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:

  • Ein Schlüssel mit den Berechtigungen „Einlagen abfragen" und „Orders erstellen und ändern" für zwei ausgewählte Konten kann auf beiden Konten das Guthaben lesen und traden – und sonst nichts.
  • Innerhalb eines Schlüssels gibt es keine kontospezifischen Berechtigungen. Wenn deine Automatisierung auf einem Konto traden, auf einem anderen jedoch nur lesen soll, verwende zwei Schlüssel. So bleibt der potenzielle Wirkungsbereich jedes Schlüssels klar überschaubar.

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.

Hinweis:

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

Tipp:

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:

  • Direkte Operationen werden sofort ausgeführt. Trading, Earn, Guthaben-Abfragen, Hauptbuch-Abfragen und Daten-Exporte werden sofort ausgeführt – im Rahmen der Berechtigungen und Konten des Schlüssels.
  • Gesteuerte Operationen erzeugen Anfragen. Eine Auszahlung oder Adressänderung, die von einem Schlüssel ausgelöst wird, durchläuft dieselbe Pipeline wie eine von einem Member ausgelöste: Die Richtlinie des Workflows entscheidet, ob sie sofort abgeschlossen wird oder in der Genehmigungswarteschlange auf menschliche Prüfung wartet.

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:

  • Unterschiedliche Administratoren. Du kannst einem Operations-Engineer erlauben, Schlüssel zu verwalten, ohne dass er den Zugang von Members ändern kann – und umgekehrt.
  • Unterschiedliche Richtlinien. Die Schlüsselverwaltung kann eigene Genehmigungsvoraussetzungen haben. Viele Organisationen verlangen eine unabhängige Genehmigung zum Erstellen oder Ändern eines Schlüssels – ein neues Credential ist ein neuer Zugangspunkt zu deinen Konten –, während der Widerruf schnell möglich bleiben soll.
  1. Navigiere zu API-Schlüssel und wähle Schlüssel erstellen.
  2. Benenne den Schlüssel nach seinem Zweck – dem System, das er bedient, und was er dort tut – damit seine Funktion bei Überprüfungen und Sicherheitsereignissen sofort erkennbar ist.
  3. Wähle die Berechtigungen des Schlüssels aus.
  4. Wähle die Konten aus, auf die der Schlüssel Zugriff haben soll. Die Berechtigungen gelten für alle ausgewählten Konten einheitlich.
  5. Konfiguriere die Sicherheitseinstellungen: Ablaufdatum, IP-Beschränkungen, Nonce-Fenster.
  6. Überprüfe und bestätige. Wenn die Richtlinie „API-Schlüssel verwalten" eine Genehmigung erfordert, wartet die Anfrage auf die erforderlichen Freigaben, bevor der Schlüssel ausgestellt wird.
Achtung:

Das Bearbeiten von Berechtigungen oder Konten eines Schlüssels sowie das Widerrufen eines Schlüssels folgen demselben geregelten Prozess.

Problemlösung

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.

Brauchst du Hilfe?