API-Schlüssel

API-Schlüssel sind keine Mitglieder mit Anmeldedaten. Sie folgen einem eigenen, einfacheren Berechtigungsmodell:

Die beiden Modelle sind bewusst getrennt. Mitglieder erhalten Rollen, Profile und kontoindividuelle Granularität, weil Menschen unterschiedliche Verantwortlichkeiten tragen. Schlüssel folgen einem flachen Scope-plus-Konten-Modell, weil Automatisierung eng gefasst, einheitlich und auf einen Blick prüfbar sein sollte.

Ein API-Schlüssel kombiniert zwei Einstellungen: was er darf (Berechtigungen) und wo (Konten).

Berechtigungen

Konto-Zuordnung

Jeder Schlüssel wird einem oder mehreren Konten zugeordnet – die Auswahl erfolgt bei der Erstellung und kann nachträglich 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 Guthaben lesen und traden – und sonst nichts.
• Innerhalb eines Schlüssels gibt es keine kontospezifischen Unterschiede. Wenn deine Automatisierung auf einem Konto traden, aber ein anderes nur lesen soll, verwende zwei Schlüssel. So bleibt der Wirkungsbereich jedes Schlüssels überschaubar.

Bei Bedarf ein bestimmtes Konto wählen

Private API-Anfragen verwenden das primäre Konto der Organisation, wenn account_id nicht angegeben wird:

Um auf einem bestimmten Konto zu arbeiten, ü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 erweitert weder die Kontoverknüpfung noch die Berechtigungen des Schlüssels. Kann der Schlüssel auf dem ausgewählten Konto nicht operieren, wird die Anfrage abgelehnt.

FIX-Konnektivität

Schlüssel mit Order-Berechtigungen unterstützen FIX-Konnektivität für Spot-Trading – ergänzend zu den REST- und WebSocket-APIs. Eine FIX-Session übernimmt die Berechtigungen und die Kontoverknüpfung des zugrunde liegenden Schlüssels: Sie tradet ausschließlich auf den ausgewählten Konten des Schlüssels, innerhalb seiner Berechtigungen. Unternehmen, die FIX-Order-Flow betreiben, verwenden in der Regel einen dedizierten Schlüssel pro Session, der auf die Konten des jeweiligen Desks beschränkt ist.

Sicherheitseinstellungen

Die Governance der Organisation gilt sowohl für die Aktionen der Schlüssel als auch für deren Verwaltung.

Was Schlüssel tun

Die Zwei-Kategorien-Regel für Mitglieder gilt für Schlüssel gleichermaßen:

• Direkte Operationen werden sofort ausgeführt. Trading, Earn, Guthabenabfragen, Hauptbuchabfragen und Datenexporte werden sofort abgeschlossen – im Rahmen der Berechtigungen und Konten des Schlüssels.
• Governance-pflichtige Operationen erzeugen Anfragen. Eine Auszahlung oder Adressänderung, die ein Schlüssel initiiert, durchläuft dieselbe Pipeline wie eine durch ein Mitglied initiierte: Die Workflow-Richtlinie entscheidet, ob sie sofort abgeschlossen wird oder in der Genehmigungswarteschlange auf eine manuelle Prüfung wartet.

Ein Schlüssel kann ausschließlich governance-pflichtige Anfragen initiieren. Schlüssel haben nie Genehmigungsrechte – das Vier-Augen-Prinzip erfordert für jede Genehmigung ein menschliches Mitglied, und ein Skript kann dieses Urteil nicht ersetzen. Wenn die Auszahlungsanfragen-Richtlinie zwei Genehmigungen erfordert, wartet eine vom Schlüssel initiierte Auszahlung auf zwei Mitglieder – genau wie eine von einem Mitglied initiierte.

Ein erfolgreicher Aufruf ist keine abgeschlossene Auszahlung

Berücksichtige diese Asynchronität in deiner Automatisierung. WithdrawFunds gibt approval_request_id zusammen mit refid zurück:

• refid bestätigt, dass die Anfrage existiert – nicht, dass Einlagen bewegt wurden. Der Betrag wird bei Einreichung auf dem Quellkonto gesperrt und erst abgewickelt, wenn die Anfrage genehmigt wurde. Siehe Einlagen werden bei der Einreichung gesperrt.
• approval_request_id ist der Bezeichner für die Genehmigung, auf die die Auszahlung wartet. Speichere ihn zusammen mit deiner eigenen Aufzeichnung der Auszahlung.
• 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.

Eine Automatisierung, die refid als Abschlussnachweis wertet, meldet Auszahlungen als abgeschlossen, während sie noch in der Genehmigungswarteschlange warten. Eine Abstimmung, die daraus schließt, dass „nicht in WithdrawStatus" bedeutet „nie eingereicht", liefert für ausstehende und abgelehnte Anfragen falsche Ergebnisse.

Schlüssel haben zudem keinen Zugang zu den administrativen Workflows. Die Verwaltung von Teamzugriffen, API-Schlüsseln, Konten, Adressen (über das Starten von Adressanfragen hinaus) und Richtlinien ist ausschließlich Mitgliedern vorbehalten.

Verwaltung von Schlüsseln

Das Erstellen, Bearbeiten und Widerrufen von API-Schlüsseln ist ein gesteuerter Vorgang im dedizierten Workflow „API-Schlüssel verwalten", der vom Workflow „Team & Zugriff verwalten" getrennt ist. Die Trennung ist aus zwei Gründen wichtig:

• Unterschiedliche Administratoren. Du kannst einem Operations-Engineer die Verwaltung von Schlüsseln erlauben, ohne dass er die Zugriffsrechte von Mitgliedern ändern kann – und umgekehrt.
• Unterschiedliche Richtlinien. Die Schlüsselverwaltung kann eigene Genehmigungsanforderungen haben. Viele Organisationen verlangen eine unabhängige Genehmigung zum Erstellen oder Ändern eines Schlüssels – ein neues Credential ist ein neuer Zugang zu deinen Konten –, während der Widerruf schnell bleiben soll.

1. Gehe zu API-Schlüssel und wähle Schlüssel erstellen.
2. Benenne den Schlüssel nach seinem Zweck – dem System, das er bedient, und seiner Funktion –, damit seine Aufgabe 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 zugreifen soll. Die Berechtigungen gelten einheitlich für alle Konten.
5. Konfiguriere die Sicherheitseinstellungen: Ablaufdatum, IP-Einschränkungen, Nonce-Fenster.
6. Überprüfe die Angaben 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.

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

Der API-Aufruf hat eine Auszahlungsanfrage erstellt, die gemäß der Auszahlungsanfragen-Richtlinie auf Genehmigung wartet. Prüfe die Seite „Anfragen" – die Anfrage erscheint dort mit dem Schlüssel als Initiator und wartet auf die erforderlichen Mitglieder-Genehmigungen. Das ist die Governance-Logik in Aktion: Automatisierung schlägt vor, Menschen genehmigen.

Der Betrag ist während der Wartezeit auf dem Quellkonto gesperrt und damit bereits für die Auszahlung reserviert. Verfolge die Anfrage anhand der approval_request_id, die mit dem Aufruf zurückgegeben wurde.

Das betroffene Konto ist nicht im Konto-Mapping des Schlüssels enthalten. Ein Schlüssel operiert ausschließlich auf den ihm zugewiesenen Konten. Bearbeite den Schlüssel, um das Konto hinzuzufügen – beachte, dass dort der vollständige Berechtigungsumfang des Schlüssels gilt, da Schlüssel keine kontenspezifischen Abstufungen unterstützen. Ist das zu weitreichend, erstelle einen zweiten Schlüssel, der nur auf das neue Konto beschränkt ist.

Ein einzelner Schlüssel kann die Berechtigungen nicht je 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 Geltungsbereich lassen sich außerdem leichter prüfen und sicherer widerrufen.

Der Workflow „API-Schlüssel verwalten" erfordert wahrscheinlich eine Genehmigung, und die Anfrage ist noch ausstehend. Der Schlüssel wird erst ausgestellt und sein Secret angezeigt, nachdem alle erforderlichen Genehmigungen eingeholt wurden. Prüfe den Status der Anfrage auf der Seite „Anfragen".

Nein. Eine Genehmigung erfordert immer ein menschliches Mitglied. Dies ist eine Systemregel, keine konfigurierbare Richtlinie – sie sorgt dafür, dass die Mehr-Parteien-Genehmigung sinnvoll bleibt, wenn automatisierte Prozesse Geldbewegungen anstoßen.