Zugangsdaten-API-Referenz
Portal-Logins über drei Endpunkte im Tresor verwalten: Anlegen mit Freigabe-Scope, Auflisten nur der Feldnamen, Widerrufen — Auslesen gibt es nicht.
Zuletzt aktualisiert:
Der Tresor hält Portal-Logins, damit ein Agent sich anmelden kann, ohne dass ein Geheimnis je in einen Prompt gerät. Seine API-Oberfläche ist bewusst klein — anlegen, auflisten, widerrufen — und asymmetrisch: Was hineingeht, kommt nie wieder heraus. Aufrufe authentifizieren sich auf dem Standardweg, ein API-Schlüssel hinter Bearer im Authorization-Header.
/v1/credentials
Speichert Zugangsdaten und antwortet mit 201 und dem Datensatz — Feldnamen, nie Werte.
Create-Body
| Name | Typ | Beschreibung |
|---|---|---|
name
erforderlich
|
string | Ein Label, bis zu 120 Zeichen. |
url
erforderlich
|
string | Definiert den Freigabe-Scope: die registrierbare Site, auf der diese Zugangsdaten je getippt werden dürfen, und nirgendwo sonst. |
fields
erforderlich
|
object | Mindestens ein `name: value`-Paar; Werte werden mit deinem Mandantenschlüssel versiegelt und nur in einer Session, auf der freigegebenen Site, im Moment des Tippens freigegeben. |
totpSeed
|
string | Ein TOTP-Seed; Codes werden serverseitig erzeugt, der Seed verlässt die Plattform also nie. |
nonSecretFields
|
string[] | Bis zu 16 Feldnamen, die du als nicht geheim deklarierst, etwa einen Benutzernamen. |
/v1/credentials
Listet deine Zugangsdaten, ausschließlich als Metadaten.
Kein Auslesen — mit Absicht
Ein gelisteter Eintrag zeigt id, name, grantUrl (beachte: das url aus dem Create-Body kommt unter diesem Namen zurück), die Feldnamen, hasTotp, nonSecretFields und die Zeitstempel createdAt, lastUsedAt und revokedAt. Es gibt keinen Endpunkt, der einen gespeicherten Wert zurückgibt, und keiner ist geplant: Der Planner arbeitet mit opaken Platzhaltern, und ein Platzhalter ohne Tresor-Freigabe wird abgelehnt statt wörtlich getippt.
/v1/credentials/:id
Widerruft die Zugangsdaten — ein Widerruf, keine Löschung: Der Datensatz behält sein `revokedAt`.
Hinweis · Selbst gehostet ohne Schlüssel-Provider
Auf einem selbst gehosteten Deployment braucht der Tresor einen Schlüssel-Provider — OVHcloud KMS oder, außerhalb der Produktion, einen lokalen KEK. Ohne ihn antworten diese Endpunkte mit 503 `capacity_unavailable` und benennen die fehlende Konfiguration.
Login speichern, Namen listen
Legt Zugangsdaten mit Scope auf ein Portal an und listet sie zurück — nur Namen.
Voraussetzungen: api-key kek
BASE="https://browserberg.com"
AUTH="Authorization: Bearer $BROWSERBERG_API_KEY"
JSON="Content-Type: application/json"
# Create: the URL defines the only site this credential may ever be typed on.
curl -s -X POST "$BASE/v1/credentials" -H "$AUTH" -H "$JSON" -d '{
"name": "Example portal",
"url": "https://portal.example.com/login",
"fields": { "username": "buchhaltung@firma.example", "password": "not-a-real-password" },
"nonSecretFields": ["username"]
}' | python3 -m json.tool
# List: field NAMES only. There is no read-back endpoint, by design.
curl -s "$BASE/v1/credentials" -H "$AUTH" \
| python3 -c 'import json,sys; print(json.dumps(json.load(sys.stdin)["credentials"], indent=2))'