Zum Hauptinhalt springen
POST
curl
Die Ereignisaufnahme ist optional. Aktivieren Sie sie unter Transactions > Settings > Event monitoring, bevor Sie Ereignisse senden. Bis dahin antwortet dieser Endpoint mit 403 und "code": "event_monitoring_disabled".
Die Ereignisaufnahme behandelt den Envelope, die zehn Kategorien, die erforderlichen Payload-Schlüssel und die Aufbewahrungsklassen. Regeln für Ereignisse erklären, welche Regeln direkt in der Anfrage ausgeführt werden und welche asynchron laufen. Um Ereignisse aus einem Browser oder einer App statt aus Ihrem Backend zu senden, verwenden Sie die SDK-Ereignisübermittlung.

Autorisierungen

x-api-key
string
header
erforderlich

Der API-Schlüssel Ihrer Anwendung, aus Entwickler -> API-Schlüssel in der Business Console. Der Primärschlüssel hat Vollzugriff. Ein benannter Schlüssel kann im Geltungsbereich eingeschränkt werden: keine, Lese- oder Schreibberechtigung pro Ressource, beschränkt auf bestimmte Workflows oder genehmigte Sitzungen, auf eine Liste von IP-Adressen und auf ein Ablaufdatum. 401 bedeutet, dass der Schlüssel falsch, widerrufen oder abgelaufen ist; 403 bedeutet, dass kein Schlüssel gesendet wurde, der Schlüssel keinen Zugriff auf diese Ressource oder Aktion hat oder die Anfrage von einer Adresse außerhalb seiner IP-Liste stammte; 404 bei einer Sitzungsroute bedeutet, dass die Sitzung außerhalb der Workflows oder Status des Schlüssels liegt. Ein Schlüssel ohne Medienzugriff erhält Bild-, Video- und PDF-URLs als null, und ein Schlüssel ohne Schreibberechtigung für Sitzungen erhält Sitzungslinks und Token als null. Siehe https://docs.didit.me/console/api-keys.

Body

application/json

Der Event-Envelope, identisch für jede Kategorie. camelCase-Aliase werden akzeptiert: eventId, eventCategory (oder category), actionType, occurredAt, timeZone (oder zoneId), deviceContext (oder device), transactionContext, customValues (oder props); innerhalb von subject: vendorData, entityType, fullName; innerhalb von session: sessionId, pageUrl; innerhalb von transaction_context: paymentReferenceId.

event_id
string
erforderlich

Ihre Kennung für das Ereignis, eindeutig pro Anwendung. Sie ist der Idempotenzschlüssel: Das erneute Senden derselben Werte für event_category, action_type, occurred_at, subject.vendor_data und payload unter dieser Kennung ist eine Wiederholung, jede Abweichung ist ein Konflikt.

Maximum string length: 128
Beispiel:

"login-2026-10-17-000001"

event_category
enum<string>
erforderlich

Ereigniskategorie.

Verfügbare Optionen:
auth,
session,
gameplay,
bonus,
affiliate,
payment,
dispute,
security,
responsible_gambling,
custom
Beispiel:

"auth"

action_type
string
erforderlich

Was innerhalb der Kategorie passiert ist. Offenes Vokabular; die in Ereigniserfassung aufgeführten verwalteten Aktionen (beispielsweise login, deposit_completed, chargeback_opened) schalten eine typisierte Validierung und verwaltete Regelfelder frei. Führende und nachfolgende Leerzeichen werden gekürzt.

Required string length: 1 - 128
Beispiel:

"login"

occurred_at
string<date-time>
erforderlich

Wann das Ereignis auf Ihrer Seite stattgefunden hat, ISO 8601 (ein Wert ohne Offset wird als UTC interpretiert). Darf nicht mehr als 7 Tage in der Vergangenheit und nicht mehr als 5 Minuten in der Zukunft liegen.

Beispiel:

"2026-10-17T09:15:02.481Z"

subject
object
erforderlich

Der Benutzer oder das Unternehmen, zu dem das Ereignis gehört. Es verweist auf den Benutzer (oder das Unternehmen) mit diesen vendor_data in Ihrer Anwendung; falls keines vorhanden ist, wird eines erstellt.

time_zone
string | null

Zeitzone des Ereignisses auf Ihrer Seite, zum Beispiel Europe/Madrid. Wird mit dem Ereignis gespeichert; wird von den Lese-Endpoints nicht zurückgegeben.

Maximum string length: 64
business
object

Das Unternehmen, zu dem das Ereignis gehört, sofern es sich vom Subjekt unterscheidet. Es wird nur vendor_data gelesen.

session
object

Ihr Sitzungskontext für das Ereignis.

device_context
object

Geräte- und Netzwerkkontext, wird so gespeichert, wie er gesendet wird, und von GET /v3/events/{event_uuid}/ zurückgegeben. Auf dieser Serverstrecke sieht Didit die Verbindung des Endbenutzers nicht, daher ist die IP, die angereichert und von Regeln verwendet wird, network_context.ip_address, wie Sie sie übermitteln.

transaction_context
object

Finanzkontext. Nicht leere Werte hier erfüllen auch die erforderlichen Payload-Schlüssel der Aktion.

payload
object

Die Domänenfelder der Kategorie, nach der JSON-Codierung maximal 16384 Bytes groß. Einige Aktionen erfordern Schlüssel (in payload oder transaction_context): gameplay.p2p_settlement erfordert game_id, counterparty_vendor_data, stake_amount, net_result_amount, role und eines von hand_id, round_id, match_id; gameplay.bet_placed und gameplay.bet_settled erfordern game_id; payment.deposit_initiated, payment.deposit_completed, payment.withdrawal_requested und payment.withdrawal_completed erfordern payment_reference_id, amount, currency, payment_method, status; payment.withdrawal_address_changed erfordert withdrawal_address_hash; dispute.chargeback_opened, dispute.chargeback_won und dispute.chargeback_lost erfordern payment_reference_id und eines von dispute_id, chargeback_id; session.bot_signal_observed erfordert telemetry_schema_version und eines von bot_score, actions_per_minute, timing_variance_ms, pointer_entropy, keystroke_entropy, reaction_time_ms_p50; responsible_gambling.self_exclusion_match erfordert registry_source, exclusion_status, identity_match_ref. Jede security-Aktion, die auf _changed endet, erfordert changed_field sowie previous_reference_hash oder new_reference_hash, wenn das Feld password, mfa_method, mfa, email, phone, withdrawal_address, payout_method oder api_key ist. Senden Sie Hashes und Referenzen, niemals eine Kartennummer, eine vollständige Auszahlungsadresse, einen Passwort-Hash oder ein MFA-Geheimnis.

custom_values
object

Bis zu 100 eigene Schlüssel, die aus Regeln als custom_values.<key> adressierbar sind. Werte müssen Skalare sein (Zeichenfolge, Zahl, boolescher Wert oder null); verschachtelte Objekte und Arrays werden abgelehnt.

Antwort

Idempotente Wiederholung: Ein Ereignis mit dieser event_id und demselben Inhalt ist bereits gespeichert. Es wurde nichts erneut gespeichert oder ausgewertet; der Body beschreibt das gespeicherte Ereignis.

Ergebnis der Erfassung eines Ereignisses. Für ein neues Ereignis und eine idempotente Wiederholung wird dieselbe Struktur zurückgegeben.

event_uuid
string<uuid>
erforderlich

Didit-Kennung des gespeicherten Ereignisses.

event_id
string
erforderlich

Ihre event_id.

status
enum<string>
erforderlich

Status nach Ausführung der Echtzeitregeln. Siehe MonitoringEvent.status.

Verfügbare Optionen:
ACCEPTED,
APPROVED,
IN_REVIEW,
DECLINED
score
integer
erforderlich

Score nach Ausführung der Echtzeitregeln.

rules_evaluated_count
integer
erforderlich

Anzahl der in der Anfrage ausgewerteten Ereignisregeln. 0 in einer Sandbox-Anwendung, in der keine Regeln ausgeführt werden.

Erforderlicher Bereich: x >= 0
rules_matched_count
integer
erforderlich

Anzahl der zutreffenden Regeln, einschließlich Regeln im TEST-Modus.

Erforderlicher Bereich: x >= 0
correlation_pending
boolean
erforderlich

true, wenn eine asynchrone Regel noch ausgeführt werden muss. Rufen Sie einige Minuten später GET /v3/events/{event_uuid}/ auf, um den endgültigen status und score zu erhalten.

retention_class
enum<string>
erforderlich

Aufbewahrungsklasse nach einer Hochstufung durch eine zutreffende Regel.

Verfügbare Optionen:
low_value,
standard,
risk_relevant,
monetary_or_compliance
expires_at
string<date-time> | null
erforderlich

Wann das Ereignis gemäß seiner Aufbewahrungsklasse abläuft und gelöscht wird. Null für monetary_or_compliance-Ereignisse (Zahlungen und Streitfälle).

idempotent_replay
boolean
erforderlich

true, wenn ein Ereignis mit dieser event_id und demselben Inhalt bereits gespeichert war; die Werte entsprechen denen des gespeicherten Ereignisses und es wurde keine Regel erneut ausgeführt.

rule_matches
object[]
erforderlich

Regeln, die auf das Ereignis zutrafen.

Zuletzt geändert am 7. November 2026