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

# عمليات المستخدمين: إنشاء مستخدمي البائع وإدارتهم

> إنشاء كيانات المستخدمين لدى مزوّد Didit وقراءتها وتحديثها وتغيير حالتها وحذفها عبر 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>



      
      

الصق في

تتم إدارة كيان المستخدم الأساسي عبر endpoints عامة تحت `/v3/users/`. أما مرفقات الملف الشخصي، مثل رفع الوجه المستورد، فتستخدم مسار المؤسسة/التطبيق مع `didit_internal_id`. تقدم لك هذه الصفحة شرحاً مفاهيمياً، راجع [مرجع API](https://docs.didit.me/ar/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/ar/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/ar/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/ar/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/ar/management-api/biometric-templates/overview.md) المحفوظة لهم بعد حذف الجلسة. لا يشمل هذا endpoint جلسات التحقق الخاصة بهم، إذ تبقى هذه الجلسات مع مسح ارتباطها بالمستخدم؛ احذفها باستخدام [حذف الجلسة](https://docs.didit.me/ar/sessions-api/delete-session.md) أو [حذف الجلسات بالدفعات](https://docs.didit.me/ar/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/ar/console/api-keys.md) إلى صلاحية **الأشخاص** (`users`): القراءة لنقاط endpoint من نوع `GET`، والكتابة للإنشاء والتحديث وتغيير الحالة والحذف.
يتطلب إنشاء مستخدم باستخدام `send_verification_link: true` أيضاً صلاحية الكتابة في **الجلسات**، لأنه ينشئ جلسة ويرسل رابطها بالبريد الإلكتروني.
يُرجع المفتاح الذي يفتقر إلى الصلاحية المطلوبة الرمز `403`.
لا يمكن لمفتاح مقيّد ببعض سير العمل أو بالجلسات المقبولة الوصول إلى endpoints `/v3/users/*` إطلاقاً.الأدوار مفهوم خاص بـ Console: مورد الإذن `users` ومطالباته تحدد ما يمكن لعضو الفريق فعله في Console، ولا تُقيَّم في طلبات مفاتيح API.
راجع [الأدوار والأذونات](https://docs.didit.me/ar/console/roles-permissions.md) للاطلاع على هذه المصفوفة.لمنع خدمة ما من حذف المستخدمين، امنحها مفتاحاً بصلاحية **الأشخاص** للقراءة فقط، أو بدون أي صلاحية للأشخاص.## حدود المعدل وidempotency- تخضع كل endpoint من `/v3/users/*` لـ[حدود المعدل](https://docs.didit.me/ar/integration/rate-limiting.md) القياسية.
- لا تتسم `create` بخاصية idempotency، فإعادة المحاولة بالقيمة `vendor_data` نفسها تُرجع خطأ تعارض. أزِل التكرار من جهتك، أو نفّذ `GET` دائماً أولاً.
- تتسم `delete` بخاصية idempotency، فحذف مستخدم محذوف مسبقاً لا يُحدث أي تغيير.## أحداث webhook التي تُطلقها هذه العمليات| العملية | Webhook |
| - | - |
| `create` | لا يوجد webhook لعملية الإنشاء نفسها، ويصل أول حدث `user.data.updated` عندما تملأ جلسة أو عملية تحديث الحقول الشخصية للمرة الأولى |
| `update` | `user.data.updated` (مع `changed_fields`) |
| `update-status` | `user.status.updated` |
| `delete` | لا يوجد. سجّل عملية الحذف في نظامك إن احتجت إلى الاستجابة لها |## الخطوات التالية> [card] [نموذج البيانات](https://docs.didit.me/ar/entities/users/data-model.md)
>
> المرجع الكامل للحقول.> [card] [واجهة API للقائمة](https://docs.didit.me/ar/management-api/users/list.md)
>
> مخطط GET /v3/users/.> [card] [واجهة API للإنشاء](https://docs.didit.me/ar/management-api/users/create.md)
>
> مخطط POST /v3/users/create/.> [card] [رفع الوجه](https://docs.didit.me/ar/management-api/users/upload-face.md)
>
> إرفاق صور الوجه المستوردة بملفات تعريف المستخدمين.


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