> ## 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.

# Opérations utilisateurs : CRUD fournisseurs

> Créez, consultez, mettez à jour, changez le statut et supprimez les utilisateurs Didit via l'API de gestion. Tarification à l'usage, sans contrat.



Prompt de l'opération sur les utilisateurs
        Copier le prompt dans le presse-papiers



      
      

\<pre>

\````# Goal — full CRUD over Didit User entities

Core CRUD operations sit under `https://verification.didit.me/v3/users/` authenticated with `x-api-key: $DIDIT_API_KEY`. Profile attachment endpoints use the organization/application path and the User's `didit_internal_id`. Each User is keyed by `vendor_data` (case-sensitive, unique per application).

\## Endpoint catalog

\| Action | Method + path |
\|---|---|
\| List users | `GET /v3/users/` |
\| Get one user | `GET /v3/users/{vendor_data}/` |
\| Create user | `POST /v3/users/create/` |
\| Upload profile face | `POST /v3/organization/{organization_id}/application/{application_id}/vendor-users/by-id/{didit_internal_id}/faces/upload/` |
\| Update profile | `PATCH /v3/users/{vendor_data}/` |
\| Change status | `PATCH /v3/users/{vendor_data}/update-status/` |
\| Batch delete | `POST /v3/users/delete/` |

\## List (with filters)

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

\## Get one user

\```bash
curl https://verification.didit.me/v3/users/user-42/ \
-H "x-api-key: $DIDIT_API_KEY"
\```

\## Create

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

Not idempotent — retrying with the same `vendor_data` returns conflict. `GET` first or PATCH instead.

\## Upload an imported profile face

\```bash
\# First read didit_internal_id from GET /v3/users/{vendor_data}/
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: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"image": "<base64-encoded-jpg-or-png>", "comment": "Imported from previous KYC provider"}'
\```

This attaches a trusted face image to the User profile and enrolls it for duplicate detection and face search. It does not add the face to a blocklist.

\## Update profile

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

Mutable: `display_name`, `metadata`, `tags`. Read-only (verified): `full_name`, `date_of_birth`, `portrait_image`, all aggregate counters, `features` map.

\## Change status

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

Valid statuses: `ACTIVE`, `FLAGGED`, `BLOCKED`. `BLOCKED` users have new sessions auto-declined.

\## Batch delete

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

Idempotent — already-deleted is a no-op. Returns a count, `{"deleted": <int>}`, not a per-item result. The user records and every biometric template retained for them are removed permanently. Verification sessions are not covered by this endpoint; delete those with the session delete endpoints.

\## Webhooks fired

\| Operation | Event |
\|---|---|
\| create | none for the create call itself — the first `user.data.updated` arrives when a session or a PATCH first fills the profile |
\| update (PATCH) | `user.data.updated` with `changed_fields` |
\| update-status | `user.status.updated` |
\| delete | none — record the deletion on your own side if you need to react to it |

\## Failure modes

\- `401` — missing / invalid `x-api-key`.
\- `403` — the API key is not valid for this application.
\- `409` on create — `vendor_data` already exists; switch to PATCH.
\- `404` — no entity for that `vendor_data` (case-sensitive!).
\- `429` — rate-limited; back off using `Retry-After`.

\## Response shape

See /reference/data-models and /entities/users/data-model for the full User schema.

\## Sources of truth

\- /management-api/users/list, /management-api/users/get, /management-api/users/create — per-endpoint reference
\- /entities/users/data-model — field-by-field schema
\- /entities/webhooks — entity event payloads
\- /integration/integration-prompt — canonical end-to-end prompt````

\</pre>



      
      

Coller dans

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](https://docs.didit.me/fr/management-api/users/list.md) 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.```bash theme={null}
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](https://docs.didit.me/fr/entities/users/data-model.md) complet, y compris les compteurs agrégés.```bash theme={null}
curl https://verification.didit.me/v3/users/user-42/ \
  -H "x-api-key: YOUR_API_KEY"
```> [!NOTE]
>
> `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.```bash theme={null}
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](https://docs.didit.me/fr/management-api/users/create.md#envoyer-un-lien-de-vérification) 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.```bash theme={null}
# 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](https://docs.didit.me/fr/management-api/users/upload-face.md) 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`.```bash theme={null}
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.```bash theme={null}
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](https://docs.didit.me/fr/management-api/biometric-templates/overview.md) 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](https://docs.didit.me/fr/sessions-api/delete-session.md) ou [Supprimer des sessions par lots](https://docs.didit.me/fr/management-api/sessions/batch-delete.md). Les transactions ne sont pas concernées non plus : supprimez-les depuis la Console.```bash theme={null}
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'autorisationsLes 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](https://docs.didit.me/fr/console/api-keys.md) 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](https://docs.didit.me/fr/console/roles-permissions.md) 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](https://docs.didit.me/fr/integration/rate-limiting.md) 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> [card] [Modèle de données](https://docs.didit.me/fr/entities/users/data-model.md)
>
> Référence complète des champs.> [card] [API de liste](https://docs.didit.me/fr/management-api/users/list.md)
>
> Schéma de la requête GET /v3/users/.> [card] [API de création](https://docs.didit.me/fr/management-api/users/create.md)
>
> Schéma de la requête POST /v3/users/create/.> [card] [Téléverser un visage](https://docs.didit.me/fr/management-api/users/upload-face.md)
>
> Joindre des images faciales importées aux profils utilisateur.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.