Zum Hauptinhalt springen
POST
Erstellen Sie ein Monitoring-Token
Authentifizierung ist neu, und dieser Endpoint bleibt deaktiviert, bis Didit ihn aktiviert: Bis dahin antwortet er mit 503 monitoring_unavailable.
Die Browser-SDKs und nativen SDKs rufen diesen Endpoint vom Gerät der Person aus auf; Ihr Server muss dies nicht tun. Jedes Ereignis, das mit den Zugangsdaten gesendet wird, wird im vendor_data-Feld der Person aufgezeichnet, unabhängig davon, was das Gerät angibt.

Autorisierungen

Authorization
string
header
erforderlich

Das Access Token der Person von POST /token/: ein ES256-JWT mit dem Header typ: at+jwt, gültig für maximal 5 Minuten. Nicht Ihr Didit-API-Schlüssel.

Body

application/json

Leer: Das Access-Token benennt die Person.

Antwort

Gerätezugangsdaten für die Person.

Ein kurzlebiges Geräte-Credential zum Senden der Aktivitätsereignisse der Person von ihrem Gerät an die Transaktionsüberwachung. Es ist nicht an die Sitzung gebunden: Es bleibt bis expires_at nutzbar, selbst nach dem Abmelden.

monitoring_token
string
erforderlich

Das Geräte-Credential. Behandeln Sie es als Geheimnis.

Beispiel:

"mt_2f8c1d9e7b6a5f4e3d2c1b0a"

expires_at
string<date-time>
erforderlich

Höchstens 15 Minuten nach der Ausstellung.

Beispiel:

"2026-10-17T10:56:14Z"

allowed_event_categories
string[]
erforderlich

Die Ereigniskategorien, die es senden darf. Authentifizierungs- und Sicherheitsereignisse stammen immer von Didit, niemals vom Gerät.

Beispiel:
max_uses
integer
erforderlich
Beispiel:

1000

bind_to_origin
string | null
erforderlich

Der Browser-Origin, von dem aus der Credential funktioniert: der Origin der Anfrage oder null, wenn keiner vorhanden war.

Beispiel:

"https://app.example.com"

vendor_data
string
erforderlich

Die Person, für die jedes Ereignis erfasst wird, unabhängig davon, was das Gerät übermittelt.

Beispiel:

"user-42"

Zuletzt geändert am 7. November 2026