Opérations utilisateurs : CRUD fournisseurs

La gestion de l’entité utilisateur principale s’effectue via les endpoints publics sous /v3/users/. Les pièces jointes au profil, comme le téléversement d’un visage importé, utilisent le chemin organisation/application avec didit_internal_id. Cette page vous présente la démarche conceptuelle : consultez la référence de l’API pour les schémas complets des requêtes et des réponses.

Lister les utilisateurs

GET /v3/users/ Renvoie une liste paginée des utilisateurs de votre application. Prend en charge des filtres sur le statut, la recherche, la plage de dates et plus encore.

curl -G https://verification.didit.me/v3/users/ \
  -H "x-api-key: YOUR_API_KEY" \
  --data-urlencode "status=ACTIVE" \
  --data-urlencode "search=jane" \
  --data-urlencode "page_size=50"

Cas d’usage :

Synchroniser chaque jour un sous-ensemble d’utilisateurs vers votre entrepôt de données.
Trouver les utilisateurs signalés pour la file d’attente pour les analystes.
Rechercher des utilisateurs par nom d’affichage.

Récupérer un utilisateur

GET /v3/users/{vendor_data}/ Récupère un seul utilisateur par vendor_data. Renvoie le modèle de données complet, y compris les compteurs agrégés.

curl https://verification.didit.me/v3/users/user-42/ \
  -H "x-api-key: YOUR_API_KEY"

vendor_data dans l’URL est sensible à la casse. Transmettez toujours la valeur exacte utilisée lors de la création de la session.

Créer un utilisateur

POST /v3/users/create/ Crée une entité Utilisateur avant l’exécution de toute session. Cela est utile pour :

Renseigner des métadonnées ou des champs personnalisés avant que le client ne procède à la vérification.
Définir un statut initial (par exemple FLAGGED pendant que votre équipe d’onboarding examine des documents manuellement).
Charger des utilisateurs depuis une base de données existante afin de disposer d’une liste complète dès le premier jour.

curl -X POST https://verification.didit.me/v3/users/create/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vendor_data": "user-42",
    "display_name": "Jane Doe",
    "metadata": { "tier": "premium", "signup_source": "web" }
  }'

Si un utilisateur avec ce vendor_data existe déjà, l’appel renvoie une erreur de conflit : utilisez PATCH pour le mettre à jour à la place. Vous pouvez aussi transmettre les coordonnées : first_name et last_name (concaténés dans full_name si vous n’envoyez pas ce champ), email, phone_number et country. Didit stocke email et phone_number dans metadata.contact, et country dans metadata.address. Pour inviter la personne à effectuer sa vérification dans le même appel, ajoutez send_verification_link: true avec un email et un workflow_id. Didit crée une session de vérification pour la personne sur ce workflow et lui envoie le lien par e-mail. Le verification_link de la réponse contient les champs session_id, session_number, status, url, workflow_id et email de la session ; il vaut null si vous ne demandez pas de lien. Consultez Créer un utilisateur pour les vérifications et les erreurs.

Téléverser un visage importé

POST /v3/organization/{organization_id}/application/{application_id}/vendor-users/by-id/{didit_internal_id}/faces/upload/ Associe une image de visage de confiance à un profil utilisateur existant. C’est la bonne étape à suivre lorsque vous importez des utilisateurs depuis un autre fournisseur et que vous voulez que Didit conserve leur preuve faciale avant la première session Didit.

# First create or retrieve the User and read didit_internal_id from the response.
curl -X POST https://verification.didit.me/v3/organization/$ORGANIZATION_ID/application/$APPLICATION_ID/vendor-users/by-id/$DIDIT_INTERNAL_ID/faces/upload/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "image": "<base64-encoded-jpg-or-png>",
    "comment": "Imported from previous KYC provider"
  }'

Consultez Téléverser le visage d’un utilisateur pour les champs de la requête, les limites, les endpoints de liste et de suppression, ainsi que la distinction avec la liste de blocage.

Mettre à jour un utilisateur

PATCH /v3/users/{vendor_data}/ Met à jour les champs de profil modifiables. La plupart des champs issus des sessions vérifiées sont en lecture seule : une tentative de modification via PATCH sera soit ignorée, soit signalée dans le journal d’audit. Champs modifiables : display_name, metadata, tags. En lecture seule après vérification : full_name, date_of_birth, portrait_image, tous les compteurs agrégés, la carte features.

curl -X PATCH https://verification.didit.me/v3/users/user-42/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "metadata": { "tier": "enterprise" } }'

Émet un webhook user.data.updated contenant le tableau changed_fields.

Modifier le statut

PATCH /v3/users/{vendor_data}/update-status/ Fait passer un utilisateur entre ACTIVE, FLAGGED et BLOCKED. Les changements de statut s’appliquent aux sessions et aux transactions à venir.

curl -X PATCH https://verification.didit.me/v3/users/user-42/update-status/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "BLOCKED",
    "reason": "Chargeback fraud pattern detected"
  }'

De → vers	Déclencheur courant
`ACTIVE` → `FLAGGED`	Règle de transaction, examen par un analyste, correspondance lors de la surveillance AML continue
`ACTIVE` → `BLOCKED`	Fraude confirmée, ajout manuel à la liste de blocage, correspondance avec la liste de blocage
`FLAGGED` → `ACTIVE`	Examen validé par un analyste
`BLOCKED` → `ACTIVE`	Déblocage manuel par un analyste

Émet un webhook user.status.updated.

Supprimer des utilisateurs (par lots)

POST /v3/users/delete/ Supprime un ou plusieurs utilisateurs. Les enregistrements d’utilisateurs sont supprimés définitivement, ainsi que tous les gabarits biométriques conservés pour eux après la suppression de leurs sessions. Leurs sessions de vérification ne sont pas concernées par cet endpoint : elles subsistent, leur lien avec l’utilisateur étant effacé. Supprimez-les avec Supprimer une session ou Supprimer des sessions par lots. Les transactions ne sont pas concernées non plus : supprimez-les depuis la Console.

curl -X POST https://verification.didit.me/v3/users/delete/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vendor_data_list": ["user-42", "user-43", "user-44"]
  }'

Sélectionnez les utilisateurs par vendor_data_list, par didit_internal_id_list, ou par les deux à la fois ; ou transmettez delete_all: true pour supprimer tous les utilisateurs de l’application. Les paramètres de lot filter_* de la Console sont rejetés ici avec un code 400 plutôt qu’ignorés, afin qu’une intention restreinte ne puisse jamais devenir une suppression totale. Renvoie un nombre, {"deleted": <int>}, et non un résultat par élément. Les identifiants qui ne correspondent à rien sont ignorés silencieusement ; envoyez donc une liste dédoublonnée si vous voulez comparer deleted au nombre d’identifiants envoyés.

Modèle d’autorisations

Les clés API appartiennent à une seule application. La clé secrète principale et les clés à accès complet peuvent appeler tous les endpoints /v3/users/* de cette application, y compris delete. Une clé API à portée limitée a besoin de l’accès Personnes (users) : lecture pour les endpoints GET, et écriture pour créer, mettre à jour, modifier le statut et supprimer. Créer un utilisateur avec send_verification_link: true nécessite aussi l’écriture sur Sessions, car cela crée une session et envoie son lien par e-mail. Une clé qui ne dispose pas de l’accès requis renvoie 403. Une clé limitée à certains workflows ou à des sessions approuvées ne peut pas du tout atteindre les endpoints /v3/users/*. Les rôles sont un concept de la Console : la ressource d’autorisation users et ses revendications déterminent ce qu’un membre de l’équipe peut faire dans la Console, et ils ne sont pas évalués pour les requêtes effectuées avec une clé API. Consultez Rôles et autorisations pour la matrice correspondante. Pour empêcher un service de supprimer des utilisateurs, attribuez-lui une clé avec accès Personnes en lecture seule, ou sans aucun accès à Personnes.

Limites de débit et idempotence

Tous les endpoints /v3/users/* sont soumis aux limites de débit standard.
create n’est pas idempotent : réessayer avec le même vendor_data renvoie un conflit. Dédoublonnez de votre côté, ou effectuez toujours un GET au préalable.
delete est idempotent : supprimer un utilisateur déjà supprimé est une opération sans effet.

Webhooks déclenchés par ces opérations

Opération	Webhook
`create`	aucun pour l’appel de création lui-même : le premier `user.data.updated` arrive lorsqu’une session ou une mise à jour remplit pour la première fois le profil
`update`	`user.data.updated` (avec `changed_fields`)
`update-status`	`user.status.updated`
`delete`	aucun : enregistrez la suppression de votre côté si vous devez y réagir

Prochaines étapes

Modèle de données

Référence complète des champs.

API de liste

Schéma de la requête GET /v3/users/.

API de création

Schéma de la requête POST /v3/users/create/.

Téléverser un visage

Joindre des images faciales importées aux profils utilisateur.

Présentation

Tarifs

Workflows et vérification

Examen et opérations

Entités (utilisateurs et entreprises)

Paramètres et personnalisation

Sécurité et conformité

Didit Academy

Ressources

Opérations utilisateurs : CRUD fournisseurs

Lister les utilisateurs

Récupérer un utilisateur

Créer un utilisateur

Téléverser un visage importé

Mettre à jour un utilisateur

Modifier le statut

Supprimer des utilisateurs (par lots)

Modèle d’autorisations

Limites de débit et idempotence

Webhooks déclenchés par ces opérations

Prochaines étapes

Modèle de données

API de liste

API de création

Téléverser un visage

​Lister les utilisateurs

​Récupérer un utilisateur

​Créer un utilisateur

​Téléverser un visage importé

​Mettre à jour un utilisateur

​Modifier le statut

​Supprimer des utilisateurs (par lots)

​Modèle d’autorisations

​Limites de débit et idempotence

​Webhooks déclenchés par ces opérations

​Prochaines étapes

Modèle de données

API de liste

API de création

Téléverser un visage

Lister les utilisateurs

Récupérer un utilisateur

Créer un utilisateur

Téléverser un visage importé

Mettre à jour un utilisateur

Modifier le statut

Supprimer des utilisateurs (par lots)

Modèle d’autorisations

Limites de débit et idempotence

Webhooks déclenchés par ces opérations

Prochaines étapes