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

# Операции с пользователями: CRUD для пользователей вендора

> Создание, чтение, обновление, смена статуса и удаление сущностей User Didit через Management API. Оплата за использование, без контрактов.



Промпт для операций с пользователями
        Скопировать промпт в буфер обмена



      
      

\<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>



      
      

Вставьте в

Управление основными сущностями пользователей выполняется через публичные endpoint'ы по пути `/v3/users/`. Вложения профиля, например загрузка импортированного лица, выполняются по пути organization/application с `didit_internal_id`. Эта страница даёт концептуальный обзор. Полные схемы запросов и ответов см. в [справочнике API](https://docs.didit.me/ru/management-api/users/list.md).## Список пользователей**`GET /v3/users/`**Возвращает постраничный список пользователей вашего приложения. Поддерживаются фильтры по статусу, поиску, диапазону дат и другим параметрам.```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"
```Сценарии использования:- Ежедневная синхронизация части пользователей с вашим хранилищем данных.
- Поиск помеченных пользователей для очереди аналитика.
- Поиск пользователей по отображаемому имени.## Получение пользователя**`GET /v3/users/{vendor_data}/`**Получает одного пользователя по `vendor_data`. Возвращает полную [модель данных](https://docs.didit.me/ru/entities/users/data-model.md), включая агрегированные счётчики.```bash theme={null}
curl https://verification.didit.me/v3/users/user-42/ \
  -H "x-api-key: YOUR_API_KEY"
```> [!NOTE]
>
> `vendor_data` в URL чувствителен к регистру. Всегда передавайте точное значение, которое использовали при создании сессии.## Создание пользователя**`POST /v3/users/create/`**Создаёт сущность пользователя до запуска любой сессии. Это полезно для:- Заполнения метаданных или пользовательских полей до того, как клиент пройдёт верификацию.
- Установки начального статуса (например, `FLAGGED`, пока ваша команда онбординга проверяет документы вручную).
- Предварительной загрузки пользователей из существующей базы данных, чтобы с первого дня иметь полный список.```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" }
  }'
```Если пользователь с таким `vendor_data` уже существует, вызов возвращает ошибку конфликта. Для обновления используйте `PATCH`.Также можно передать контактные данные: `first_name` и `last_name` (объединяются в `full_name`, если вы не передали его), `email`, `phone_number` и `country`.
Didit сохраняет `email` и `phone_number` в `metadata.contact`, а `country` в `metadata.address`.Чтобы пригласить человека пройти верификацию в том же вызове, добавьте `send_verification_link: true` вместе с `email` и `workflow_id`.
Didit создаёт для него сессию верификации по этому сценарию и отправляет ему ссылку по электронной почте.
Ответ `verification_link` содержит `session_id`, `session_number`, `status`, `url`, `workflow_id` и `email` сессии. Если ссылку не запрашивали, поле равно `null`.
Проверки и ошибки см. в разделе [Создание пользователя](https://docs.didit.me/ru/management-api/users/create.md#отправка-ссылки-на-верификацию).## Загрузка импортированного лица**`POST /v3/organization/{organization_id}/application/{application_id}/vendor-users/by-id/{didit_internal_id}/faces/upload/`**Прикрепляет доверенное изображение лица к существующему профилю пользователя. Это правильный следующий шаг, если вы импортируете пользователей от другого провайдера и хотите, чтобы Didit сохранил подтверждение их лица до первой сессии 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"
  }'
```См. [Загрузка лица пользователя](https://docs.didit.me/ru/management-api/users/upload-face.md): поля запроса, ограничения, endpoint'ы для получения и удаления, а также различие между загрузкой лица и списком блокировки.## Обновление пользователя**`PATCH /v3/users/{vendor_data}/`**Обновляет изменяемые поля профиля. Большинство полей, полученных из проверенных сессий, доступны только для чтения. Попытка изменить их через PATCH либо будет проигнорирована, либо отмечена в журнале аудита.**Изменяемые поля:** `display_name`, `metadata`, `tags`.
**Доступны только для чтения после верификации:** `full_name`, `date_of_birth`, `portrait_image`, все агрегированные счётчики, карта `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" } }'
```Генерирует webhook `user.data.updated` с массивом `changed_fields`.## Изменение статуса**`PATCH /v3/users/{vendor_data}/update-status/`**Переводит пользователя между статусами `ACTIVE`, `FLAGGED` и `BLOCKED`. Изменения статуса применяются к будущим сессиям и транзакциям.```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"
  }'
```| Из → в | Типичный триггер |
| - | - |
| `ACTIVE` → `FLAGGED` | Правило для транзакций, проверка аналитиком, срабатывание при постоянном AML-мониторинге |
| `ACTIVE` → `BLOCKED` | Подтверждённое мошенничество, ручное добавление в список блокировки, совпадение со списком блокировки |
| `FLAGGED` → `ACTIVE` | Аналитик завершил проверку |
| `BLOCKED` → `ACTIVE` | Ручная разблокировка аналитиком |Генерирует webhook `user.status.updated`.## Удаление пользователей (пакетное)**`POST /v3/users/delete/`**Удаляет одного или нескольких пользователей. Записи пользователей удаляются безвозвратно вместе со всеми [биометрическими шаблонами](https://docs.didit.me/ru/management-api/biometric-templates/overview.md), сохранёнными для них после удаления сессии. Их сессии верификации этим endpoint'ом не удаляются: они сохраняются, а связь с пользователем очищается. Удалите их с помощью [Удаление сессии](https://docs.didit.me/ru/sessions-api/delete-session.md) или [Пакетное удаление сессий](https://docs.didit.me/ru/management-api/sessions/batch-delete.md). Транзакции тоже не затрагиваются. Удалите их в 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"]
  }'
```Выбирайте пользователей по `vendor_data_list`, по `didit_internal_id_list` или сразу по обоим спискам. Либо передайте `delete_all: true`, чтобы удалить всех пользователей приложения. Пакетные параметры `filter_*` из Console отклоняются с кодом `400`, а не игнорируются, поэтому сужение выборки никогда не превратится в полную очистку.Возвращает количество в виде `{"deleted": <int>}`, а не результат по каждому элементу. Идентификаторы, которые ни с чем не совпали, молча пропускаются. Поэтому, если хотите сверить `deleted` с числом отправленных идентификаторов, отправляйте список без дубликатов.## Модель разрешенийAPI-ключи принадлежат одному приложению.
Основной секретный ключ и ключи с полным доступом могут вызывать все endpoint'ы `/v3/users/*` этого приложения, включая `delete`.[API-ключ с ограниченными правами](https://docs.didit.me/ru/console/api-keys.md) должен иметь доступ **Люди** (`users`): чтение для endpoint'ов `GET`, а для создания, обновления, изменения статуса и удаления требуется право на запись.
Создание пользователя с `send_verification_link: true` также требует права записи для **Сессии**, так как при этом создаётся сессия и отправляется её ссылка по электронной почте.
Ключ без нужного доступа возвращает `403`.
Ключ, ограниченный отдельными сценариями или одобренными сессиями, вообще не может обращаться к endpoint'ам `/v3/users/*`.Роли относятся к Console. Ресурс разрешений `users` и его утверждения определяют, что может делать член команды в Console, а для запросов с API-ключами они не проверяются.
Матрицу см. в разделе [Роли и разрешения](https://docs.didit.me/ru/console/roles-permissions.md).Чтобы не позволить сервису удалять пользователей, выдайте ему ключ с доступом **Люди** только на чтение или без доступа к **Люди**.## Лимиты запросов и идемпотентность- На все endpoint'ы `/v3/users/*` распространяются стандартные [лимиты запросов](https://docs.didit.me/ru/integration/rate-limiting.md).
- `create` **не** идемпотентен: повторная отправка с тем же `vendor_data` возвращает конфликт. Устраняйте дубликаты на своей стороне или всегда сначала выполняйте `GET`.
- `delete` идемпотентен: удаление уже удалённого пользователя ничего не меняет.## Webhooks, запускаемые этими операциями| Операция | Webhook |
| - | - |
| `create` | Нет для самого вызова создания. Первое событие `user.data.updated` приходит, когда сессия или обновление впервые заполняет профиль. |
| `update` | `user.data.updated` (с `changed_fields`) |
| `update-status` | `user.status.updated` |
| `delete` | Нет. Если нужно реагировать на удаление, фиксируйте его в собственной системе. |## Следующие шаги> [card] [Модель данных](https://docs.didit.me/ru/entities/users/data-model.md)
>
> Полный справочник полей.> [card] [API списка](https://docs.didit.me/ru/management-api/users/list.md)
>
> Схема GET /v3/users/.> [card] [API создания](https://docs.didit.me/ru/management-api/users/create.md)
>
> Схема POST /v3/users/create/.> [card] [Загрузка лица](https://docs.didit.me/ru/management-api/users/upload-face.md)
>
> Прикрепление импортированных изображений лица к профилям пользователей.


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