> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.
# API d'événements de surveillance en lot
> Envoyez jusqu'à 500 événements de surveillance par requête avec Didit, avec un résultat par élément : un événement invalide ne bloque pas le lot.
Prompt de l'API de création d'événements de surveillance en lot
Copier le prompt dans le presse-papiers
\
\`Send up to 500 monitoring events to Didit in one request from my backend, and handle the per-item outcomes.
Endpoint:
POST https://verification.didit.me/v3/events/batch/
Authentication:
Use the x-api-key header with my Didit API key, from my backend only. A scoped key needs transactions: write.
Goal:
\- Flush a queue of events (logins, gameplay rounds, payment steps, chargebacks) in as few requests as possible, without one bad event blocking the others.
Request body (application/json):
\{
"events": [ { ...one event, same envelope as POST /v3/events/... }, ... ] // 1 to 500 events
}
A bare JSON array of events is also accepted.
Behavior:
\- Each item is validated, stored and evaluated on its own, exactly like POST /v3/events/. A rejected item never rolls back the others.
\- HTTP 201 when no item was rejected, 207 when at least one was. Treat both as success and read results[].
\- results[] has one entry per item in request order, with index pointing into my events array and outcome accepted, replayed or rejected.
\- accepted and replayed items carry the same fields as the single-event response (event_uuid, status, score, rule_matches, correlation_pending, retention_class, expires_at, idempotent_replay).
\- rejected items carry errors keyed by field, in the same shape as the 400 of POST /v3/events/. A reused event_id with different content is reported as a string under errors.event_id. Send event_id in snake_case so a rejected item's results[].event_id is filled.
\- Retry only the rejected items after fixing them. Resending an accepted item is safe: it comes back as replayed.
\- occurred_at must still be within 7 days in the past and 5 minutes in the future for every item.
Example call:
curl -X POST "https://verification.didit.me/v3/events/batch/" \
-H "x-api-key: YOUR_API_KEY" -H "Content-Type: application/json" \
-d '{"events":[{"event_id":"login-2026-10-17-000001","event_category":"auth","action_type":"login","occurred_at":"2026-10-17T09:15:02.481Z","subject":{"vendor_data":"user-42"}}]}'
What to read from the response:
\- accepted_count, replayed_count, rejected_count.
\- results[].index and results[].outcome.
\- results[].errors for rejected items.
\- results[].event_uuid and results[].status for stored items.
Failure modes:
\- 400 - events missing, not an array, empty, or longer than 500 items ({ "events": "" }). Nothing is stored; split the batch.
\- 429 - more than 600 ingestion requests per minute for this API key (event and transaction ingestion share this budget, apart from the 300 of every other write); honor Retry-After.
\- 401 - the API key has expired.
\- 403 - missing API key (a wrong, revoked or expired key gets 401), a scoped key without transactions: write, or code event_monitoring_disabled (event ingestion is not switched on; nothing is stored).
Side effects: stores every valid item, may create subjects, and applies the actions of matched active rules.
For the full integration shape, see /integration/integration-prompt.`
\
Coller dans
Voir [Lots](https://docs.didit.me/fr/transaction-monitoring/events.md#lots) dans le guide d'ingestion des événements. Le flux de l'appareil produit les mêmes résultats par élément lors des flushs du SDK : voir [Envoi d'événements via le SDK](https://docs.didit.me/fr/transaction-monitoring/sdk-event-submission.md#envoi-groupé).
## OpenAPI
````yaml fr/openapi-25.json POST /v3/events/batch/
openapi: 3.0.0
info:
version: 3.0.0
title: Didit Verification API
description: API de vérification d'identité. Authentifiez-vous avec l'en-tête x-api-key.
servers:
- url: https://verification.didit.me
security: []
tags: []
paths:
/v3/events/batch/:
post:
tags:
- Monitoring Events
summary: Créer des événements de surveillance par lot
description: >-
Soumettez 1 à 500 événements en une seule requête, chacun dans la même
enveloppe que `POST /v3/events/`. Chaque élément est validé, stocké et
évalué individuellement et reçoit son propre résultat (`accepted`,
`replayed` ou `rejected`), de sorte qu'un événement malformé n'annule
jamais les autres : la réponse est `201` lorsqu'aucun élément n'a été
rejeté et `207` lorsqu'au moins un l'a été, les deux signifiant que la
requête a été traitée. Envoyez `{"events": [...]}` ; un simple tableau
JSON d'événements est également accepté. L'ingestion d'événements doit
être activée pour l'application, sinon la requête entière renvoie `403`
avec `code: event_monitoring_disabled` et rien n'est stocké. Une clé API
avec restriction nécessite `transactions: write`. Voir
[Lots](https://docs.didit.me/fr/transaction-monitoring/events#lots).
operationId: create_monitoring_events_batch
requestBody:
required: true
content:
application/json:
schema:
type: object
required:
- events
properties:
events:
type: array
minItems: 1
maxItems: 500
description: >-
1 à 500 événements. Chaque élément suit
`MonitoringEventCreateRequest`, y compris la fenêtre de 7
jours dans le passé et de 5 minutes dans le futur pour
`occurred_at`.
items:
$ref: '#/components/schemas/MonitoringEventCreateRequest'
example:
events:
- event_id: login-2026-10-17-000001
event_category: auth
action_type: login
occurred_at: '2026-10-17T09:15:02.481Z'
subject:
vendor_data: user-42
- event_id: deposit-2026-10-17-000002
event_category: payment
action_type: deposit_completed
occurred_at: '2026-10-17T09:16:40Z'
subject:
vendor_data: user-42
transaction_context:
amount: '100.00'
currency: EUR
payment_reference_id: dep_736
payload:
payment_method: card
status: completed
responses:
'201':
description: >-
Aucun élément n'a été rejeté : chaque élément est `accepted` ou
`replayed`.
content:
application/json:
schema:
type: object
required:
- accepted_count
- replayed_count
- rejected_count
- results
properties:
accepted_count:
type: integer
minimum: 0
description: Éléments stockés et évalués.
replayed_count:
type: integer
minimum: 0
description: Éléments déjà stockés avec le même contenu.
rejected_count:
type: integer
minimum: 0
description: Éléments non stockés.
results:
type: array
description: Une entrée par élément, dans l'ordre de la requête.
items:
type: object
description: >-
Résultat d'un élément. Les éléments acceptés et rejoués
comportent également chaque champ de
`MonitoringEventIngestResult` ; les éléments rejetés
comportent `event_id` et `errors` à la place.
required:
- index
- outcome
properties:
index:
type: integer
minimum: 0
description: Position de l'élément dans votre tableau `events`.
outcome:
type: string
enum:
- accepted
- replayed
- rejected
description: >-
`accepted` : stocké et évalué. `replayed` : déjà
stocké avec le même contenu. `rejected` : non stocké
; voir `errors`.
event_id:
type: string
nullable: true
description: >-
Votre `event_id`. Sur les éléments rejetés par la
validation, il est lu à partir de la clé snake_case
`event_id` de l'élément ; il est donc nul lorsque
l'élément l'a omis ou a envoyé l'alias `eventId`.
errors:
type: object
additionalProperties: true
description: >-
Éléments rejetés uniquement. Erreurs de validation
indexées par champ, sous le même format que le `400`
de `POST /v3/events/` ; un `event_id` réutilisé avec
un contenu différent est signalé sous forme de
chaîne sous `errors.event_id`.
event_uuid:
type: string
format: uuid
description: Éléments acceptés et rejoués uniquement.
status:
type: string
enum:
- ACCEPTED
- APPROVED
- IN_REVIEW
- DECLINED
description: Éléments acceptés et rejoués uniquement.
score:
type: integer
description: Éléments acceptés et rejoués uniquement.
rules_evaluated_count:
type: integer
description: Éléments acceptés et rejoués uniquement.
rules_matched_count:
type: integer
description: Éléments acceptés et rejoués uniquement.
correlation_pending:
type: boolean
description: Éléments acceptés et rejoués uniquement.
retention_class:
type: string
enum:
- low_value
- standard
- risk_relevant
- monetary_or_compliance
description: Éléments acceptés et rejoués uniquement.
expires_at:
type: string
format: date-time
nullable: true
description: Éléments acceptés et rejoués uniquement.
idempotent_replay:
type: boolean
description: Éléments acceptés et rejoués uniquement.
rule_matches:
type: array
description: Éléments acceptés et rejoués uniquement.
items:
type: object
required:
- rule_id
- library_key
- mode
- is_async
properties:
rule_id:
type: string
format: uuid
description: UUID de la règle.
library_key:
type: string
nullable: true
description: >-
Clé de bibliothèque lorsque la règle a été
installée depuis la bibliothèque de règles,
sinon null.
mode:
type: string
enum:
- ACTIVE
- TEST
description: >-
Les règles `TEST` enregistrent la
correspondance mais n'appliquent aucune
action.
is_async:
type: boolean
description: >-
`true` lorsque la correspondance provient de
la passe asynchrone.
examples:
All landed:
value:
accepted_count: 1
replayed_count: 1
rejected_count: 0
results:
- index: 0
outcome: accepted
event_uuid: 33333333-4444-5555-6666-777777777777
event_id: login-2026-10-17-000001
status: ACCEPTED
score: 0
rules_evaluated_count: 6
rules_matched_count: 0
correlation_pending: false
retention_class: standard
expires_at: '2026-11-16T09:15:02.481000Z'
idempotent_replay: false
rule_matches: []
- index: 1
outcome: replayed
event_uuid: 11111111-2222-3333-4444-555555555555
event_id: deposit-2026-10-17-000002
status: ACCEPTED
score: 0
rules_evaluated_count: 6
rules_matched_count: 0
correlation_pending: false
retention_class: monetary_or_compliance
expires_at: null
idempotent_replay: true
rule_matches: []
'207':
description: "Au moins un élément a été rejeté. Les autres éléments ont été stockés\_; corrigez et renvoyez uniquement les éléments rejetés (le renvoi d'un élément accepté est sans risque, il revient avec le statut `replayed`)."
content:
application/json:
schema:
type: object
required:
- accepted_count
- replayed_count
- rejected_count
- results
properties:
accepted_count:
type: integer
minimum: 0
description: Éléments stockés et évalués.
replayed_count:
type: integer
minimum: 0
description: Éléments déjà stockés avec le même contenu.
rejected_count:
type: integer
minimum: 0
description: Éléments non stockés.
results:
type: array
description: Une entrée par élément, dans l'ordre de la requête.
items:
type: object
description: >-
Résultat d'un élément. Les éléments acceptés et rejoués
comportent également chaque champ de
`MonitoringEventIngestResult` ; les éléments rejetés
comportent `event_id` et `errors` à la place.
required:
- index
- outcome
properties:
index:
type: integer
minimum: 0
description: Position de l'élément dans votre tableau `events`.
outcome:
type: string
enum:
- accepted
- replayed
- rejected
description: >-
`accepted` : stocké et évalué. `replayed` : déjà
stocké avec le même contenu. `rejected` : non stocké
; voir `errors`.
event_id:
type: string
nullable: true
description: >-
Votre `event_id`. Sur les éléments rejetés par la
validation, il est lu à partir de la clé snake_case
`event_id` de l'élément ; il est donc nul lorsque
l'élément l'a omis ou a envoyé l'alias `eventId`.
errors:
type: object
additionalProperties: true
description: >-
Éléments rejetés uniquement. Erreurs de validation
indexées par champ, sous le même format que le `400`
de `POST /v3/events/` ; un `event_id` réutilisé avec
un contenu différent est signalé sous forme de
chaîne sous `errors.event_id`.
event_uuid:
type: string
format: uuid
description: Éléments acceptés et rejoués uniquement.
status:
type: string
enum:
- ACCEPTED
- APPROVED
- IN_REVIEW
- DECLINED
description: Éléments acceptés et rejoués uniquement.
score:
type: integer
description: Éléments acceptés et rejoués uniquement.
rules_evaluated_count:
type: integer
description: Éléments acceptés et rejoués uniquement.
rules_matched_count:
type: integer
description: Éléments acceptés et rejoués uniquement.
correlation_pending:
type: boolean
description: Éléments acceptés et rejoués uniquement.
retention_class:
type: string
enum:
- low_value
- standard
- risk_relevant
- monetary_or_compliance
description: Éléments acceptés et rejoués uniquement.
expires_at:
type: string
format: date-time
nullable: true
description: Éléments acceptés et rejoués uniquement.
idempotent_replay:
type: boolean
description: Éléments acceptés et rejoués uniquement.
rule_matches:
type: array
description: Éléments acceptés et rejoués uniquement.
items:
type: object
required:
- rule_id
- library_key
- mode
- is_async
properties:
rule_id:
type: string
format: uuid
description: UUID de la règle.
library_key:
type: string
nullable: true
description: >-
Clé de bibliothèque lorsque la règle a été
installée depuis la bibliothèque de règles,
sinon null.
mode:
type: string
enum:
- ACTIVE
- TEST
description: >-
Les règles `TEST` enregistrent la
correspondance mais n'appliquent aucune
action.
is_async:
type: boolean
description: >-
`true` lorsque la correspondance provient de
la passe asynchrone.
examples:
Partial success:
value:
accepted_count: 1
replayed_count: 0
rejected_count: 2
results:
- index: 0
outcome: accepted
event_uuid: 33333333-4444-5555-6666-777777777777
event_id: login-2026-10-17-000001
status: ACCEPTED
score: 0
rules_evaluated_count: 6
rules_matched_count: 0
correlation_pending: false
retention_class: standard
expires_at: '2026-11-16T09:15:02.481000Z'
idempotent_replay: false
rule_matches: []
- index: 1
event_id: deposit-2026-10-17-000002
outcome: rejected
errors:
payload:
- >-
payment.deposit_completed requires:
payment_method, status.
- index: 2
event_id: login-2026-10-16-000777
outcome: rejected
errors:
event_id: >-
event_id 'login-2026-10-16-000777' already exists
with a different payload.
'400':
description: >-
Le lot lui-même est malformé : `events` est manquant ou n'est pas un
tableau, est vide ou comporte plus de 500 éléments. Rien n'est
enregistré ; fractionnez les lots volumineux.
content:
application/json:
examples:
Not a list:
value:
events: Expected a list of events.
Empty:
value:
events: At least one event is required.
Too many:
value:
events: A batch accepts at most 500 events; received 612.
'401':
description: >-
La clé API restreinte a expiré. Seule une clé expirée renvoie `401`
; une clé manquante ou invalide renvoie `403`.
content:
application/json:
examples:
Expired key:
value:
detail: This API key has expired.
'403':
description: >-
Un en-tête `x-api-key` manquant (une clé erronée, révoquée ou
expirée renvoie `401`), une clé restreinte sans `transactions:
write`, une clé limitée à certains workflows ou à des sessions
approuvées (une telle clé n'accède jamais aux données de
surveillance des transactions), ou une requête provenant de
l'extérieur de la liste d'autorisation IP de la clé. Également
renvoyé avec `code: event_monitoring_disabled` lorsque l'ingestion
d'événements est désactivée pour l'application ; rien n'est stocké
dans ce cas, et la vérification s'exécute avant que le corps ne soit
validé.
content:
application/json:
examples:
Event monitoring disabled:
value:
detail: >-
Event monitoring is not enabled for this application. Turn
on event ingestion in the transaction monitoring settings
before submitting events.
code: event_monitoring_disabled
Missing or invalid API key:
value:
detail: You do not have permission to perform this action.
Scoped key without access:
value:
detail: This API key has no write access to transactions.
Key limited to workflows or approved sessions:
value:
detail: >-
This API key only reaches sessions inside its workflow or
status limits, so it can't use this endpoint.
IP not allowed:
value:
detail: This API key can't be used from this IP address.
'429':
description: >-
Limite de débit dépassée : les créations de transactions et
l'ingestion d'événements (`POST /v3/transactions/`, `POST
/v3/events/`, `POST /v3/events/batch/`) partagent un quota de 600
requêtes par minute par clé API, distinct des 300 requêtes partagées
par toutes les autres requêtes d'écriture. Attendez `Retry-After`
secondes, puis réessayez.
headers:
Retry-After:
description: >-
Secondes à attendre avant de réessayer, arrondies à l'unité
supérieure pour que la tentative se fasse dans la fenêtre
suivante.
schema:
type: integer
minimum: 1
example: 30
content:
application/json:
examples:
Throttled:
value:
detail: >-
Ingestion rate limit exceeded. You can make up to 600
requests per minute.
security:
- ApiKeyAuth: []
x-codeSamples:
- lang: curl
label: curl
source: |-
curl -X POST 'https://verification.didit.me/v3/events/batch/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"events": [
{"event_id": "login-2026-10-17-000001", "event_category": "auth", "action_type": "login",
"occurred_at": "2026-10-17T09:15:02.481Z", "subject": {"vendor_data": "user-42"}},
{"event_id": "deposit-2026-10-17-000002", "event_category": "payment", "action_type": "deposit_completed",
"occurred_at": "2026-10-17T09:16:40.000Z", "subject": {"vendor_data": "user-42"},
"transaction_context": {"amount": "100.00", "currency": "EUR", "payment_reference_id": "dep_736"},
"payload": {"payment_method": "card", "status": "completed"}}
]
}'
- lang: python
label: Python
source: |-
from didit import Didit
# Reads DIDIT_API_KEY.
client = Didit()
result = client.monitoring_events.create_batch(
events=[{
"event_id": "login-2026-10-17-000001",
"event_category": "auth",
"action_type": "login",
"occurred_at": "2026-10-17T09:15:02.481Z",
"subject": {
"vendor_data": "user-42",
},
}, {
"event_id": "deposit-2026-10-17-000002",
"event_category": "payment",
"action_type": "deposit_completed",
"occurred_at": "2026-10-17T09:16:40Z",
"subject": {
"vendor_data": "user-42",
},
"transaction_context": {
"amount": "100.00",
"currency": "EUR",
"payment_reference_id": "dep_736",
},
"payload": {"payment_method": "card", "status": "completed"},
}],
)
print(result)
- lang: javascript
label: Node.js
source: |-
import Didit from "@didit-protocol/sdk-node";
// Reads DIDIT_API_KEY.
const didit = new Didit();
const result = await didit.monitoringEvents.createBatch({
events: [{
event_id: "login-2026-10-17-000001",
event_category: "auth",
action_type: "login",
occurred_at: "2026-10-17T09:15:02.481Z",
subject: {
vendor_data: "user-42",
},
}, {
event_id: "deposit-2026-10-17-000002",
event_category: "payment",
action_type: "deposit_completed",
occurred_at: "2026-10-17T09:16:40Z",
subject: {
vendor_data: "user-42",
},
transaction_context: {
amount: "100.00",
currency: "EUR",
payment_reference_id: "dep_736",
},
payload: { payment_method: "card", status: "completed" },
}],
});
console.log(result);
- lang: go
label: Go
source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.MonitoringEvents.CreateBatch(ctx, didit.MonitoringEventsCreateBatchParams{\n\tEvents: []didit.MonitoringEventCreateRequest{{\n\t\tEventID: \"login-2026-10-17-000001\",\n\t\tEventCategory: \"auth\",\n\t\tActionType: \"login\",\n\t\tOccurredAt: time.Date(2026, 10, 17, 9, 15, 2, 0, time.UTC),\n\t\tSubject: didit.MonitoringEventCreateRequestSubject{\n\t\t\tVendorData: \"user-42\",\n\t\t},\n\t}, {\n\t\tEventID: \"deposit-2026-10-17-000002\",\n\t\tEventCategory: \"payment\",\n\t\tActionType: \"deposit_completed\",\n\t\tOccurredAt: time.Date(2026, 10, 17, 9, 16, 40, 0, time.UTC),\n\t\tSubject: didit.MonitoringEventCreateRequestSubject{\n\t\t\tVendorData: \"user-42\",\n\t\t},\n\t\tTransactionContext: didit.Some(didit.MonitoringEventCreateRequestTransactionContext{\n\t\t\tAmount: didit.String(\"100.00\"),\n\t\t\tCurrency: didit.String(\"EUR\"),\n\t\t\tPaymentReferenceID: didit.String(\"dep_736\"),\n\t\t}),\n\t\tPayload: didit.Some(map[string]any{\"payment_method\": \"card\", \"status\": \"completed\"}),\n\t}},\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)"
- lang: java
label: Java
source: >-
import java.time.OffsetDateTime;
import java.util.List;
import java.util.Map;
import me.didit.Didit;
import me.didit.types.MonitoringEventCreateRequest;
import me.didit.types.MonitoringEventsCreateBatchParams;
// Reads DIDIT_API_KEY.
Didit client = new Didit();
var result =
client.monitoringEvents().createBatch(MonitoringEventsCreateBatchParams.builder()
.events(List.of(
MonitoringEventCreateRequest.builder()
.eventId("login-2026-10-17-000001")
.eventCategory(MonitoringEventCreateRequest.EventCategory.of("auth"))
.actionType("login")
.occurredAt(OffsetDateTime.parse("2026-10-17T09:15:02.481Z"))
.subject(MonitoringEventCreateRequest.Subject.builder()
.vendorData("user-42")
.build())
.build(),
MonitoringEventCreateRequest.builder()
.eventId("deposit-2026-10-17-000002")
.eventCategory(MonitoringEventCreateRequest.EventCategory.of("payment"))
.actionType("deposit_completed")
.occurredAt(OffsetDateTime.parse("2026-10-17T09:16:40Z"))
.subject(MonitoringEventCreateRequest.Subject.builder()
.vendorData("user-42")
.build())
.transactionContext(MonitoringEventCreateRequest.TransactionContext.builder()
.amount("100.00")
.currency("EUR")
.paymentReferenceId("dep_736")
.build())
.payload(Map.of("payment_method", "card", "status", "completed"))
.build()))
.build());
System.out.println(result);
- lang: php
label: PHP
source: |-
monitoringEvents->createBatch([
'events' => [[
'event_id' => 'login-2026-10-17-000001',
'event_category' => 'auth',
'action_type' => 'login',
'occurred_at' => '2026-10-17T09:15:02.481Z',
'subject' => [
'vendor_data' => 'user-42',
],
], [
'event_id' => 'deposit-2026-10-17-000002',
'event_category' => 'payment',
'action_type' => 'deposit_completed',
'occurred_at' => '2026-10-17T09:16:40Z',
'subject' => [
'vendor_data' => 'user-42',
],
'transaction_context' => [
'amount' => '100.00',
'currency' => 'EUR',
'payment_reference_id' => 'dep_736',
],
'payload' => ['payment_method' => 'card', 'status' => 'completed'],
]],
]);
print_r($result->toArray());
- lang: ruby
label: Ruby
source: |-
require "didit"
# Reads DIDIT_API_KEY.
didit = Didit::Client.new
result = didit.monitoring_events.create_batch(
events: [{
event_id: "login-2026-10-17-000001",
event_category: "auth",
action_type: "login",
occurred_at: "2026-10-17T09:15:02.481Z",
subject: {
vendor_data: "user-42",
},
}, {
event_id: "deposit-2026-10-17-000002",
event_category: "payment",
action_type: "deposit_completed",
occurred_at: "2026-10-17T09:16:40Z",
subject: {
vendor_data: "user-42",
},
transaction_context: {
amount: "100.00",
currency: "EUR",
payment_reference_id: "dep_736",
},
payload: { payment_method: "card", status: "completed" },
}]
)
puts result.to_h
- lang: csharp
label: .NET
source: >-
using System;
using System.Collections.Generic;
using System.Text.Json;
using Didit;
// Reads DIDIT_API_KEY.
using var client = new DiditClient();
var result = await client.MonitoringEvents.CreateBatchAsync(new
MonitoringEventsCreateBatchParams
{
Events = new MonitoringEventCreateRequest[]
{
new()
{
EventId = "login-2026-10-17-000001",
EventCategory = "auth",
ActionType = "login",
OccurredAt = DateTimeOffset.Parse("2026-10-17T09:15:02.481Z"),
Subject = new()
{
VendorData = "user-42",
},
},
new()
{
EventId = "deposit-2026-10-17-000002",
EventCategory = "payment",
ActionType = "deposit_completed",
OccurredAt = DateTimeOffset.Parse("2026-10-17T09:16:40Z"),
Subject = new()
{
VendorData = "user-42",
},
TransactionContext = new MonitoringEventCreateRequestTransactionContext
{
Amount = "100.00",
Currency = "EUR",
PaymentReferenceId = "dep_736",
},
Payload = new Dictionary { ["payment_method"] = "card", ["status"] = "completed" },
},
},
});
Console.WriteLine(JsonSerializer.Serialize(result));
components:
schemas:
MonitoringEventCreateRequest:
type: object
description: >-
L'enveloppe de l'événement, identique pour chaque catégorie. Les alias
en camelCase sont acceptés : `eventId`, `eventCategory` (ou `category`),
`actionType`, `occurredAt`, `timeZone` (ou `zoneId`), `deviceContext`
(ou `device`), `transactionContext`, `customValues` (ou `props`) ; dans
`subject` : `vendorData`, `entityType`, `fullName` ; dans `session` :
`sessionId`, `pageUrl` ; dans `transaction_context` :
`paymentReferenceId`.
required:
- event_id
- event_category
- action_type
- occurred_at
- subject
properties:
event_id:
type: string
maxLength: 128
description: >-
Votre identifiant pour l'événement, unique par application. Il
s'agit de la clé d'idempotence : renvoyer les mêmes
`event_category`, `action_type`, `occurred_at`,
`subject.vendor_data` et `payload` sous cet identifiant constitue un
rejeu, toute modification constitue un conflit.
example: login-2026-10-17-000001
event_category:
type: string
enum:
- auth
- session
- gameplay
- bonus
- affiliate
- payment
- dispute
- security
- responsible_gambling
- custom
description: Catégorie d'événement.
example: auth
action_type:
type: string
minLength: 1
maxLength: 128
description: >-
Ce qui s'est passé au sein de la catégorie. Vocabulaire ouvert ; les
actions gérées listées dans [Event
ingestion](https://docs.didit.me/fr/transaction-monitoring/events)
(par exemple `login`, `deposit_completed`, `chargeback_opened`)
débloquent la validation typée et les champs de règles gérées. Les
espaces de début et de fin sont supprimés.
example: login
occurred_at:
type: string
format: date-time
description: >-
Date et heure de l'événement de votre côté, ISO 8601 (une valeur
sans fuseau horaire est lue comme UTC). Ne doit pas dater de plus de
7 jours dans le passé ni dépasser 5 minutes dans le futur.
example: '2026-10-17T09:15:02.481Z'
time_zone:
type: string
nullable: true
maxLength: 64
description: >-
Fuseau horaire de l'occurrence de votre côté, par exemple
`Europe/Madrid`. Enregistré avec l'événement ; non renvoyé par les
endpoints de lecture.
subject:
type: object
description: >-
L'utilisateur ou l'entreprise auquel appartient l'événement. Il
correspond à l'utilisateur (ou l'entreprise) ayant ce `vendor_data`
dans votre application ; un utilisateur ou une entreprise est
créé(e) lorsqu'il n'en existe aucun(e).
required:
- vendor_data
properties:
vendor_data:
type: string
minLength: 1
maxLength: 255
description: Votre identifiant pour le sujet.
example: user-42
entity_type:
type: string
maxLength: 32
default: individual
description: >-
`company` associe le sujet à une entreprise ; toute autre valeur
(`individual` par défaut) l'associe à un individu. Un même
`vendor_data` peut désigner une entreprise et un individu.
example: individual
full_name:
type: string
nullable: true
maxLength: 512
description: >-
Nom d'affichage, utilisé uniquement lorsque cet événement crée
l'utilisateur ou l'entreprise.
email:
type: string
format: email
nullable: true
description: Validé comme adresse e-mail ; non stocké sur l'événement.
phone:
type: string
nullable: true
maxLength: 32
description: Validé ; non stocké sur l'événement.
country:
type: string
nullable: true
maxLength: 3
description: Validé ; non stocké sur l'événement.
business:
type: object
description: >-
L'entreprise à laquelle appartient l'événement, lorsqu'elle diffère
du sujet. Seul `vendor_data` est lu.
additionalProperties: true
properties:
vendor_data:
type: string
maxLength: 255
description: >-
Votre identifiant pour l'entreprise. Filtrable via
`business_vendor_data`.
example: merchant-7
session:
type: object
description: Le contexte de votre session pour l'événement.
properties:
session_id:
type: string
nullable: true
maxLength: 255
description: >-
Votre identifiant de session. Filtrable et renvoyé sous la forme
`session_id`.
sequence:
type: integer
nullable: true
description: >-
Position de l'événement au sein de la session. Renvoyée sous
`session_sequence`.
page_url:
type: string
nullable: true
maxLength: 2048
description: Validé ; non stocké sur l'événement.
referrer:
type: string
nullable: true
maxLength: 2048
description: Validé ; non stocké sur l'événement.
device_context:
type: object
additionalProperties: true
description: >-
Contexte de l'appareil et du réseau, stocké tel quel et renvoyé par
`GET /v3/events/{event_uuid}/`. Sur cette voie serveur, Didit ne
voit pas la connexion de l'utilisateur final ; l'IP enrichie et
utilisée par les règles est donc `network_context.ip_address` telle
que vous l'envoyez.
properties:
fingerprint:
type: string
maxLength: 255
description: Empreinte de l'appareil. Filtrable via `device_fingerprint`.
persistent_device_id:
type: string
maxLength: 255
description: Votre identifiant d'appareil persistant.
bot_score:
type: integer
description: >-
Score de bot issu de votre propre détection, sous forme
d'entier.
network_context:
type: object
additionalProperties: true
properties:
ip_address:
type: string
maxLength: 64
description: >-
Adresse IP de l'utilisateur final. Les adresses publiques
sont enrichies une fois par adresse unique.
example: 203.0.113.42
transaction_context:
type: object
description: >-
Contexte monétaire. Les valeurs non vides ici satisfont également
les clés de payload requises de l'action.
properties:
amount:
type: string
nullable: true
description: >-
Montant sous forme de chaîne décimale (un nombre est également
accepté).
example: '1000.00'
currency:
type: string
nullable: true
maxLength: 10
description: Code devise.
direction:
type: string
nullable: true
maxLength: 16
description: >-
Direction du mouvement de fonds, par exemple `inbound` ou
`outbound`.
payment_reference_id:
type: string
nullable: true
maxLength: 255
description: >-
Votre référence de paiement. Filtrable via
`payment_reference_id`.
payload:
type: object
additionalProperties: true
description: >-
Les champs de domaine de la catégorie, au maximum 16384 octets une
fois encodés en JSON. Certaines actions requièrent des clés (dans
`payload` ou `transaction_context`) : `gameplay.p2p_settlement`
nécessite `game_id`, `counterparty_vendor_data`, `stake_amount`,
`net_result_amount`, `role` et l'un des champs `hand_id`,
`round_id`, `match_id` ; `gameplay.bet_placed` et
`gameplay.bet_settled` nécessitent `game_id` ;
`payment.deposit_initiated`, `payment.deposit_completed`,
`payment.withdrawal_requested` et `payment.withdrawal_completed`
nécessitent `payment_reference_id`, `amount`, `currency`,
`payment_method`, `status` ; `payment.withdrawal_address_changed`
nécessite `withdrawal_address_hash` ; `dispute.chargeback_opened`,
`dispute.chargeback_won` et `dispute.chargeback_lost` nécessitent
`payment_reference_id` et l'un des champs `dispute_id`,
`chargeback_id` ; `session.bot_signal_observed` nécessite
`telemetry_schema_version` et l'un des champs `bot_score`,
`actions_per_minute`, `timing_variance_ms`, `pointer_entropy`,
`keystroke_entropy`, `reaction_time_ms_p50` ;
`responsible_gambling.self_exclusion_match` nécessite
`registry_source`, `exclusion_status`, `identity_match_ref`. Chaque
action `security` se terminant par `_changed` nécessite
`changed_field`, ainsi que `previous_reference_hash` ou
`new_reference_hash` lorsque le champ est `password`, `mfa_method`,
`mfa`, `email`, `phone`, `withdrawal_address`, `payout_method` ou
`api_key`. Envoyez des hachages et des références, jamais un numéro
de carte, une adresse de retrait complète, un hachage de mot de
passe ou un secret MFA.
custom_values:
type: object
description: >-
Jusqu'à 100 clés personnalisées, adressables depuis les règles sous
la forme `custom_values.`. Les valeurs doivent être des
scalaires (chaîne, nombre, booléen ou null) ; les objets imbriqués
et les tableaux sont rejetés.
additionalProperties:
nullable: true
oneOf:
- type: string
- type: number
- type: boolean
example:
event_id: login-2026-10-17-000001
event_category: auth
action_type: login
occurred_at: '2026-10-17T09:15:02.481Z'
time_zone: Europe/Madrid
subject:
vendor_data: user-42
entity_type: individual
session:
session_id: web-session-abc
sequence: 142
device_context:
fingerprint: fp-a8c1
network_context:
ip_address: 203.0.113.42
payload:
method: password
custom_values:
vip_tier: gold
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: x-api-key
description: >-
La clé API de votre application, issue de Développeurs -> Clés API dans
la Business Console. La clé principale dispose d'un accès complet. Une
clé nommée peut être restreinte : aucun, lecture ou écriture par
ressource, limitée à certains workflows ou aux sessions approuvées, à
une liste d'adresses IP et à une date d'expiration. 401 signifie que la
clé est incorrecte, révoquée ou expirée ; 403 signifie qu'aucune clé n'a
été envoyée, que la clé n'a pas accès à cette ressource ou action, ou
que la requête provient d'une adresse hors de sa liste d'IP ; 404 sur
une route de session signifie que la session est hors des workflows ou
des statuts de la clé. Une clé sans accès aux médias reçoit les URL
d'images, de vidéos et de PDF à null, et une clé sans accès en écriture
aux sessions reçoit les liens et tokens de session à null. Voir
https://docs.didit.me/console/api-keys.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.