Zum Inhalt springen

API-Schlüssel

Alles, was von außerhalb der App mit MoneyLights verbunden ist — ein Skript, eine Integration, ein KI-Assistent — authentifiziert sich mit einem API-Schlüssel. Ein Credential-Typ, ein Ort zur Verwaltung, ein Widerruf-Button.

Gehe zu Einstellungen → API-Schlüssel als Besitzer oder Admin deiner Organisation. Ein Mitglied kann Daten in der App bearbeiten, aber keinen Schlüssel ausstellen: Ein Schlüssel agiert unbeaufsichtigt, was eine andere Art von Verantwortung ist.

Wenn du einen Schlüssel erstellst, wählst du:

  • Einen Namen — benenne ihn nach dem System, das ihn verwenden wird, nicht nach der Person.
  • Scopes — genau das, was der Schlüssel tun darf (siehe unten).
  • Ein Ablaufdatum — 30, 90, 180 oder 365 Tage. Es gibt absichtlich keine “läuft nie ab” Option: Ein Credential, an das niemand jemals wieder denkt, ist ein Credential, das niemand bemerkt hat, dass es geleakt ist.
  • Eine IP-Whitelist (optional) — beschränke den Schlüssel auf deine eigene Infrastruktur, sodass ein geleakter Schlüssel nur von dort funktioniert.

Das Geheimnis (ml_sk_…) wird einmal bei der Erstellung angezeigt. MoneyLights speichert nur einen Hash, sodass niemand — einschließlich des Supports — es später wiederherstellen kann. Wenn du es verlierst, rotiere den Schlüssel.

Gib jeder Integration ihren eigenen Schlüssel. Du kannst dann einen zurückziehen, ohne die anderen abzuschalten, und die Nutzungszahlen zeigen dir, welches System was macht.

Scopes sind resource:action Paare — zum Beispiel transactions:read oder documents:write. Ein Schlüssel hält nur die Scopes, die du ihm gewährt hast, und:

  • Schreiben impliziert Lesen, niemals umgekehrt. vendors:write kann auch Anbieter lesen; vendors:read kann niemals schreiben.
  • Scopes können nach der Erstellung nicht bearbeitet werden. Ein neuer Scope bedeutet, einen neuen Schlüssel zu erstellen — eine Erweiterung eines Credentials vor Ort wäre eine Änderung, die niemand sieht.

Was ein Schlüssel tatsächlich tun kann, wird bei jeder Anfrage neu berechnet:

effektive Berechtigungen = die Scopes des Schlüssels ∩ was sein Ersteller jetzt tun kann ∩ dein Plan

Wenn die Person, die einen Schlüssel erstellt hat, herabgestuft wird, wird der Schlüssel beim nächsten Aufruf eingeschränkt. Wenn sie die Organisation verlassen, funktionieren ihre Schlüssel sofort nicht mehr. Stelle Schlüssel unter einem Konto aus, das bleiben wird.

Die Rotation gibt ein neues Geheimnis für denselben Schlüssel aus und lässt dich wählen, wie lange der alte noch funktioniert: sofort, 24 Stunden oder 7 Tage. Das Zeitfenster existiert, damit du das neue Geheimnis ohne Ausfallzeit bereitstellen kannst. Der Schlüssel behält seinen Namen, Scopes, IP-Beschränkungen und Ablaufdatum.

Rotieren, wenn jemand mit Zugang zum Geheimnis geht, wenn es möglicherweise offengelegt wurde, und nach dem Zeitplan, den deine eigene Richtlinie festlegt.

Der Ersteller des Schlüssels wird 14, 7 und 1 Tag vor dem Ablauf eines Schlüssels benachrichtigt, und einmal, nachdem er abgelaufen ist. Diese Benachrichtigungen können nicht deaktiviert werden. Warte nicht auf die letzte: Eine Rotation nach 14 Tagen kostet ein Deployment; einen abgelaufenen Schlüssel bei null zu entdecken, kostet einen Ausfall.

  • Verwende Umgebungsvariablen oder einen Geheimnis-Manager — niemals Quellcodeverwaltung, niemals eine Konfigurationsdatei, die mit deiner App ausgeliefert wird.
  • Setze den Schlüssel niemals in eine URL, eine Protokollzeile oder ein Analyseereignis. Anfragen, die einen Schlüssel in der Abfragezeichenfolge enthalten, werden sofort abgelehnt.
  • Verwende einen Schlüssel niemals im Client-seitigen Code. Ein Schlüssel in einem Browser oder einer mobilen App wurde allen gegeben, die ihn verwenden.

Verdächtig, dass es ein Leck gibt? Widerrufe zuerst, untersuche danach. Der Widerruf erfolgt in Einstellungen → API-Schlüssel, tritt sofort in Kraft und ist immer verfügbar — auch wenn dein Abonnement im Rückstand ist.

Mit einem Schlüssel in der Hand kannst du die REST API aufrufen oder einen KI-Assistenten über MCP verbinden — es ist dasselbe Credential für beide.