Ga naar inhoud

API-sleutels

Alles wat verbinding maakt met MoneyLights van buiten de app — een script, een integratie, een AI-assistent — authenticates met een API-sleutel. Eén type inloggegevens, één plek om het te beheren, één knop om het in te trekken.

Ga naar Instellingen → API-sleutels als een Eigenaar of Beheerder van jouw organisatie. Een Lid kan gegevens in de app bewerken, maar kan geen sleutel uitgeven: een sleutel werkt onbemand, wat een andere soort verantwoordelijkheid is.

Wanneer je een sleutel aanmaakt, kies je:

  • Een naam — noem het naar het systeem dat het zal gebruiken, niet naar de persoon.
  • Scopes — precies wat de sleutel mag doen (zie hieronder).
  • Een vervaldatum — 30, 90, 180 of 365 dagen. Er is geen “verloopt nooit” optie, met opzet: een inloggegeven waar niemand ooit meer aan denkt, is een inloggegeven dat niemand opmerkt dat het is gelekt.
  • Een IP-toegangslijst (optioneel) — beperk de sleutel tot jouw eigen infrastructuur, zodat een gelekte sleutel een sleutel is die nergens anders werkt.

Het geheim (ml_sk_…) wordt eenmalig getoond, bij de creatie. MoneyLights slaat alleen een hash op, zodat niemand — inclusief support — het later kan herstellen. Als je het verliest, draaig de sleutel.

Geef elke integratie zijn eigen sleutel. Je kunt er dan één intrekken zonder de anderen uit te schakelen, en de gebruikscijfers vertellen je welk systeem wat doet.

Scopes zijn resource:action paren — bijvoorbeeld transactions:read of documents:write. Een sleutel bevat alleen de scopes die je hebt verleend, en:

  • Schrijven impliceert lezen, nooit andersom. vendors:write kan ook leveranciers lezen; vendors:read kan nooit schrijven.
  • Scopes kunnen niet worden bewerkt na creatie. Een nieuwe scope nodig hebben betekent een nieuwe sleutel aanmaken — het verbreden van een inloggegeven ter plaatse zou een wijziging zijn die niemand ziet.

Wat een sleutel daadwerkelijk kan doen, wordt opnieuw berekend bij elke aanvraag:

effectieve rechten = de scopes van de sleutel ∩ wat de maker nu kan doen ∩ jouw plan

Dus als de persoon die een sleutel heeft aangemaakt, wordt gedegradeerd, wordt de sleutel beperkt bij de volgende oproep. Als ze de organisatie verlaten, stoppen hun sleutels onmiddellijk met werken. Geef sleutels uit onder een account dat blijft bestaan.

Rotatie geeft een nieuw geheim voor dezelfde sleutel en laat je kiezen hoe lang de oude blijft werken: onmiddellijk, 24 uur of 7 dagen. Het venster bestaat zodat je het nieuwe geheim kunt implementeren zonder downtime. De sleutel behoudt zijn naam, scopes, IP-beperkingen en vervaldatum.

Rotate wanneer iemand met toegang tot het geheim vertrekt, wanneer het mogelijk is geëxposeerd, en op welk schema jouw eigen beleid ook instelt.

De maker van de sleutel wordt 14, 7 en 1 dag voor een sleutel vervalt, en een keer nadat deze is vervallen, op de hoogte gesteld. Die meldingen kunnen niet worden uitgeschakeld. Wacht niet op de laatste: roteren bij 14 dagen kost een implementatie; het ontdekken van een vervallen sleutel op nul kost een storing.

  • Gebruik omgevingsvariabelen of een geheimenbeheerder — nooit source control, nooit een configuratiebestand dat met jouw app wordt meegeleverd.
  • Zet de sleutel nooit in een URL, een logregel of een analytics-evenement. Aanvragen met een sleutel in de querystring worden outright geweigerd.
  • Gebruik nooit een sleutel in client-side code. Een sleutel in een browser of een mobiele app is gegeven aan iedereen die het gebruikt.

Verdacht van een lek? Intrekken eerst, daarna onderzoeken. Intrekking is te vinden in Instellingen → API-sleutels, heeft onmiddellijke werking, en is altijd beschikbaar — zelfs als jouw abonnement in gebreke is.

Met een sleutel in de hand, kun je de REST API aanroepen of een AI-assistent via MCP verbinden — het is dezelfde inloggegeven voor beide.