> ## 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: محو البيانات وفق GDPR > احذف مستخدمي البائع في Didit بالجملة حسب vendor_data، أو احذف كل المستخدمين في التطبيق. متوافق مع حق النسيان بموجب GDPR وCCPA. موجه حذف المستخدمين دفعةً واحدة نسخ الموجّه إلى الحافظة \

\`Goal: Permanently delete one or many Didit User entities. The matching user records, their tag links, their comment history, and every retained biometric template anchored to them are removed permanently. Verification sessions are NOT removed by this endpoint; delete those separately with POST /v3/sessions/delete/.

Endpoint: POST https://verification.didit.me/v3/users/delete/
Auth header: x-api-key: 
Content-Type: application/json

Request body — provide at least one selector:
\- vendor_data_list: string[] — your own identifiers (case-insensitive after normalisation).
\- didit_internal_id_list: string[] — Didit internal user IDs, the didit_internal_id returned by the create and get endpoints. Can be combined with vendor_data_list; the two are OR'd.
\- delete_all: true — wipe every user in this application. No confirmation, no undo. Takes precedence: when delete_all is true, the two lists are ignored.

\- retain_face_embeddings: boolean, default false — your explicit choice to keep one image-free biometric template of each deleted person for duplicate detection. Everything else about the person is deleted. Requires face_retention_days.
\- face_retention_days: integer 1 to 3650 — how many days that template is kept. Sent without retain_face_embeddings: true it returns 400 on face_retention_days.

This endpoint never narrows delete_all with filters. The Console's filter_* batch params (filter_search, filter_status, filter_country, filter_date_from, filter_date_to, filter_tag, filter_latest_verification_status, filter_risk, filter_has_sessions, filter_has_open_alerts, filter_aml_monitoring, filter_can_sign_in, filter_auth_status, filter_auth_method, filter_auth_mfa_enabled) are NOT supported here. Any of them sent with a value, even false, is rejected with a 400 keyed by that field, and any other unknown filter_* key with "Unknown filter.", so a narrowed intent does not wipe the whole application. Exception: filter_has_approved_sessions and filter_has_declined_sessions are neither rejected nor applied, so with delete_all they still delete every user. Do not send them.

curl:
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-123", "user-456"]}'

Response 200:
\{
"deleted": 
}

Biometric templates: unless you set retain_face_embeddings to true, if the application retained image-free biometric templates for these users after session deletion (see /management-api/biometric-templates/overview), Didit purges every one of them before the user is deleted, so the person stops matching in duplicate detection and Face Search. The purge is audited with instruction_source: vendor_user_delete.

Idempotency: re-sending the same list returns deleted: 0 after the first run (unmatched IDs are silently skipped). There is no undo.

Failure modes:
\- 400 — no selector supplied, or a Console-only filter_* param was sent.
No selector: {"vendor_data_list": ["This field is required unless delete_all is true."]}. An unknown filter_* key: {"filter_": ["Unknown filter."]}.
\- 401 — missing/invalid x-api-key.
\- 403 — the API key is revoked or is not valid for this application.
\- 409 — the selection includes a person in a finalized regulatory report. Nothing is deleted. The body has code: in_filed_report and reports[] with uuid, report_number, report_type and case_uuid. Delete the reports, then repeat the request.
\- 409 — code: subject_deletion_in_progress: another request is still deleting one of the selected people. This request deleted nothing; repeat it once that deletion has finished.
\- 429 — rate-limited.
\- 503 — {"detail": "The biometric-template operation could not finish because an external store is unavailable. The operation is retryable."} A retained biometric template could not be purged. No user in the request is deleted; the affected template is already excluded from matching. Repeat the same request.

WARNING — delete_all: true: there is no confirmation step and no undo. Restrict to API keys you intentionally provision for batch maintenance.

When to prefer status change instead:
\- For day-to-day blocking, use PATCH /v3/users/{vendor_data}/update-status/ with {"status": "BLOCKED"} — it keeps the audit trail intact while rejecting future sessions for the same identifier.

For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`

\
الصق في ## نظرة عامةيحذف مستخدماً واحداً أو أكثر من [كيانات المستخدمين](https://docs.didit.me/ar/entities/users/overview.md). تُزال سجلات المستخدمين نهائياً. لا يشمل هذا endpoint جلسات التحقق الخاصة بهم، فهذه الجلسات تبقى بعد الحذف مع مسح ارتباطها بالمستخدم، واحذفها باستخدام [حذف الجلسة](https://docs.didit.me/ar/sessions-api/delete-session.md) أو [حذف الجلسات دفعةً واحدة](https://docs.didit.me/ar/management-api/sessions/batch-delete.md). كما لا تشمل المعاملات، ويمكنك حذفها باستخدام [حذف المعاملات دفعةً واحدة](https://docs.didit.me/ar/management-api/transactions/delete.md).## متى تستخدمه- طلبات **الحق في النسيان** (GDPR / CCPA). - **تنظيف** المستخدمين التجريبيين أثناء ضمان الجودة. - **إلغاء توفير** المستخدمين الذين أُزيلوا من منصتك.## ملاحظات- يقبل قائمة من قيم `vendor_data`، أو قائمة من قيم `didit_internal_id`، أو `delete_all: true`. يمكن دمج القائمتين، وتُجمعان بمنطق OR. - لا يُقيّد هذا endpoint `delete_all` بالمرشحات أبداً، وتُرفض معاملات الدُفعات `filter_*` في Console بالاستجابة `400`، لذلك لا يؤدي الطلب المُقيَّد النطاق إلى حذف كل مستخدمي التطبيق. الاستثناءان هما `filter_has_approved_sessions` و`filter_has_declined_sessions`: لا يُرفضان ولا يُطبَّقان، لذا لا ترسلهما مع `delete_all`. - الكل أو لا شيء: إذا تعذّر إتمام الحذف للمستخدمين الذين اخترتهم، فلن يُحذف أيٌّ منهم، ويمكنك إعادة الطلب نفسه بأمان. - يتمتع بخاصية idempotency: إعادة إرسال القائمة نفسها تُرجع `deleted: 0` بعد التشغيل الأول. - تُرجع عدد ما حُذف فقط، لا تقريراً لكل عنصر. تُتخطى القيم التي لم تطابق أي شيء بصمت. أرسل قائمة خالية من التكرار إذا أردت مقارنة `deleted` بعدد المعرّفات التي أرسلتها، لأن المعرّف المكرر يُحسب مرة واحدة فقط. - لا يُصدر أي webhook عند الحذف. تُطلق webhooks عند تغيّر حالة المستخدم وبياناته، لا عند الحذف، لذلك يجب على أي تكامل يحتاج إلى إشارة حذف أن يسجلها على جانبه. - **لا تُحذف** جلسات التحقق المرتبطة بالمستخدم بهذا endpoint. تبقى مع مسح ارتباطها بالمستخدم، ولا تُزال مستنداتها ووجوهها ووسائطها إلا عند حذف الجلسات نفسها. - `retain_face_embeddings` (منطقي، والافتراضي `false`) و`face_retention_days` (من 1 إلى 3650) هما خيارك الصريح للاحتفاظ بقالب بيومتري واحد خالٍ من الصورة لكل شخص محذوف، لاكتشاف التكرار، لهذا العدد من الأيام. لا يُحتفظ بأي معلومة أخرى عن الشخص. اترك كليهما لحذف القوالب مع المستخدمين. يُرجع `face_retention_days` دون `retain_face_embeddings: true`، أو `retain_face_embeddings: true` دون `face_retention_days`، الاستجابة `400` على `face_retention_days`. - ما لم تضبط `retain_face_embeddings` على `true`، فإن [القوالب البيومترية](https://docs.didit.me/ar/management-api/biometric-templates/overview.md) المحفوظة المرتبطة بالمستخدم تُمحى فعلاً قبل حذف المستخدم. إذا تعذّر محو قالب لأن مخزناً بيومترياً غير متاح، تُرجع الاستجابة `503`، ولا يُحذف أي مستخدم في الطلب، وإعادة الطلب تُكمل المهمة.## البيانات في تقرير تنظيمي نهائيإذا كان أي شخص مختار طرفاً في حالة لها تقرير تنظيمي نهائي، فإن الطلب كله يُرجع `409` ولا يُحذف شيء. تحتوي الاستجابة على `code: in_filed_report` وتسمّي كل تقرير، لتتمكن من فتحه في Console:```json theme={null} { "detail": "A case about this person or company has a filed regulatory report, so it cannot be deleted.", "code": "in_filed_report", "reports": [ { "uuid": "5ec00000-0000-4000-8000-000000000007", "report_number": "SAR-0001", "report_type": "SAR", "case_uuid": "c1a5e000-0000-4000-8000-000000000001" } ] } ```احذف كل تقرير باستخدام [حذف التقرير](https://docs.didit.me/ar/management-api/regulatory-reports/delete.md)، ثم أعد الطلب نفسه. لا يكفي إزالة ذلك الشخص من القائمة إذا كان شخص آخر محدد ما زال في تقرير.## حذف جارٍ بالفعليُحذف الشخص بطلب واحد في كل مرة. إذا كان طلب آخر ما زال يحذف أحد الأشخاص المختارين، ينتظر هذا الطلب بضع ثوانٍ كحد أقصى، ثم يُرجع `409` مع `code: subject_deletion_in_progress` ولا يحذف شيئاً:```json theme={null} { "detail": "This person or company is being deleted. Retry after deletion completes.", "code": "subject_deletion_in_progress" } ```أعد الطلب نفسه بعد انتهاء الحذف الآخر. الشخص الذي حذفه ذلك الطلب لم يعد مطابقاً، لذلك لن يحذف الطلب المتكرر إلا ما تبقى.## الأذوناتيمكن لأي مفتاح API نشط للتطبيق استدعاء هذا endpoint. مفاتيح Didit API **مقيّدة بالتطبيق، لا بالدور**: تحدد [الأدوار والأذونات](https://docs.didit.me/ar/console/roles-permissions.md) في Console (`delete:users` وغيرها) ما يستطيع *الشخص* فعله داخل Console، ولا تُطبَّق على حركة Management API. للتحكم في من يستدعي هذا endpoint، تحكّم في من يمكنه قراءة مفتاح API الخاص بالتطبيق.## ذات صلة- [الاحتفاظ بالبيانات](https://docs.didit.me/ar/console/data-retention.md) - [سجلات التدقيق](https://docs.didit.me/ar/console/audit-logs.md) - [عمليات المستخدم](https://docs.didit.me/ar/entities/users/operations.md) - [القوالب البيومترية](https://docs.didit.me/ar/management-api/biometric-templates/overview.md) ## OpenAPI ````yaml ar/openapi-25.json POST /v3/users/delete/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: API التحقق من الهوية. قم بالمصادقة باستخدام الرأس x-api-key. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/users/delete/: post: tags: - Users summary: حذف المستخدمين دفعة واحدة description: >- **حذف المستخدمين نهائياً**: تتم إزالة سجلات المستخدمين نهائياً. للحظر اليومي المعتاد، يُفضّل استخدام [تحديث حالة المستخدم](#patch-/v3/users/-vendor_data-/update-status/) مع `BLOCKED`. حدد المستخدمين باستخدام `vendor_data_list`، أو `didit_internal_id_list`، أو كليهما معاً؛ أو مرّر `delete_all: true`. لا يضيق هذا الـ endpoint أبداً نطاق `delete_all` باستخدام الفلاتر. يتم رفض فلاتر الأشخاص في Console مع رمز الحالة `400` (راجع الاستجابة `400`)، بحيث لا يتحول القصد المحدود إلى مسح كامل. استثناءان: لا يتم رفض `filter_has_approved_sessions` و`filter_has_declined_sessions` ولا يتم تطبيقهما، لذا مع `delete_all: true` سيظلان يحذفان كل مستخدم؛ لا تقم بإرسالهما. **القوالب البيومترية:** ما لم تقم بتعيين `retain_face_embeddings` إلى `true`، فسيتم مسح كل قالب بيومتري خالٍ من الصور تم الاحتفاظ به لهؤلاء المستخدمين بعد حذف الجلسة (راجع `/v3/biometric-templates/`) قبل حذف المستخدم، وبذلك يتوقف الشخص عن المطابقة في كشف التكرار والبحث بالوجه (Face Search). مع تعيين `retain_face_embeddings: true` و`face_retention_days`، فإنك تختار الاحتفاظ بقالب بيومتري واحد خالٍ من الصور لكل شخص لذلك العدد من الأيام، ولن يتم الاحتفاظ بأي شيء آخر عن الشخص. إذا تعذر مسح قالب بسبب عدم توفر مخزن بيومتري، يُرجع الاستدعاء `503`، ولا يُحذف أي مستخدم في الطلب، وتؤدي إعادة إرسال الطلب إلى إتمام المهمة. **التقارير التنظيمية المُقدَّمة:** إذا كانت البيانات المحددة واردة في تقرير تنظيمي نهائي، فسيتم رفض الطلب بأكمله مع رمز الحالة `409` ولن يُحذف أي شيء. يستخدم نص الاستجابة `code: in_filed_report` ويحدد كل تقرير باستخدام `uuid` و`report_number` و`report_type` و`case_uuid`. احذف التقارير، ثم أعد إرسال الطلب. operationId: batch_delete_users requestBody: required: true content: application/json: schema: type: object description: >- قدّم `vendor_data_list`، أو `didit_internal_id_list`، أو `delete_all: true`. يمكن الجمع بين القائمتين وتطبيق معامل الربط OR بينهما. عندما تكون قيمة `delete_all` هي `true`، فإن لها الأسبقية ويتم تجاهل كلتا القائمتين. properties: vendor_data_list: type: array items: type: string description: >- المعرّفات الخاصة بك المراد حذفها، وتتم مطابقتها تماماً كما أُرسلت. didit_internal_id_list: type: array items: type: string format: uuid description: >- معرّفات المستخدم الداخلية لـ Didit المطلوب حذفها - وهو `didit_internal_id` الذي تُرجعه endpoints الخاصة بالإنشاء والجلب. delete_all: type: boolean default: false description: إذا كانت القيمة `true`، فسيتم حذف كل مستخدم في التطبيق. retain_face_embeddings: type: boolean default: false description: >- اختيارك الصريح للاحتفاظ بقالب بيومتري واحد خالٍ من الصور لكل شخص تم حذفه للكشف عن التكرار، لمدة `face_retention_days`. يتم حذف كل شيء آخر متعلق بالشخص. أغفله، أو أرسل `false`، لحذف القوالب مع المستخدمين. عندما يكون `true`، يكون `face_retention_days` مطلوباً. face_retention_days: type: integer minimum: 1 maximum: 3650 description: >- عدد الأيام التي يتم فيها الاحتفاظ بالقالب البيومتري الخالي من الصور عندما يكون `retain_face_embeddings` مضبوطاً على `true`. مطلوب معه، ويُرفض بدونه بخطأ `400` في `face_retention_days`. example: 365 examples: Specific users: summary: حذف المستخدمين بواسطة vendor_data value: vendor_data_list: - user-123 - user-456 By Didit internal ID: summary: حذف المستخدمين بواسطة didit_internal_id value: didit_internal_id_list: - 3f1c0d3e-8f0a-4c2e-9a3d-9b1f5f4a2c11 All users: summary: مسح كل المستخدمين في هذا التطبيق value: delete_all: true Keep face templates: summary: >- حذف المستخدمين والاحتفاظ بقوالب الوجه مجهولة الهوية لمدة 365 يوماً value: vendor_data_list: - user-123 retain_face_embeddings: true face_retention_days: 365 responses: '200': description: تم حذف المستخدمين. يرجع عدد المستخدمين الذين تم حذفهم بالفعل. content: application/json: schema: type: object properties: deleted: type: integer description: >- عدد المستخدمين المحذوفين (يستثني قيم vendor_data التي لم تطابق أي شيء). examples: Deleted some: value: deleted: 2 Nothing matched: value: deleted: 0 '400': description: >- خطأ في التحقق؛ لم يتم حذف أي شيء. تُفهرس الأخطاء حسب اسم الحقل. في حال عدم وجود محدد (لا توجد أي من القائمتين وقيمة `delete_all` ليست `true`)، يكون نص الاستجابة هو `{"vendor_data_list": ["This field is required unless delete_all is true."]}`؛ وتُرفض القائمة الفارغة تحت مفتاحها الخاص مع `"This list may not be empty."`. ويُرفض أي عامل تصفية مخصص لـ Console فقط (`filter_search`، أو `filter_status`، أو `filter_country`، أو `filter_date_from`، أو `filter_date_to`، أو `filter_tag`، أو `filter_latest_verification_status`، أو `filter_risk`، أو `filter_has_sessions`، أو `filter_has_open_alerts`، أو `filter_aml_monitoring`، أو `filter_can_sign_in`، أو `filter_auth_status`، أو `filter_auth_method`، أو `filter_auth_mfa_enabled`) عندما يحمل قيمة، حتى لو كانت `false`، مع كائن مفهرس بكل حقل من هذا القبيل. ويُرفض أي مفتاح `filter_*` آخر غير معروف مع `"Unknown filter."`. content: application/json: examples: Missing selector: summary: لم يتم تقديم list ولا delete_all value: vendor_data_list: - This field is required unless delete_all is true. Console-only filter: value: filter_has_sessions: >- This filter is Console-only and is not supported by this endpoint. '401': description: >- لم يتم توفير بيانات اعتماد. الطلبات المرسلة إلى مسارات `/v3/users/*` بدون رأس `x-api-key` (أو رمز `Authorization: Bearer`) يتم رفضها بواسطة برمجية المصادقة الوسيطة قبل وصولها إلى الـ API. content: application/json: examples: Missing credentials: value: detail: >- You must be authenticated with a valid access token to access this endpoint. '403': description: >- مفتاح API غير صالح أو تم إلغاؤه، أو أن المفتاح لا يملك صلاحية حذف مستخدمين لهذا التطبيق. يُرجع المفتاح المفقود `403`؛ بينما يُرجع المفتاح الخاطئ أو المُلغى أو المنتهي الصلاحية `401`. content: application/json: examples: Forbidden: value: detail: You do not have permission to perform this action. '409': description: >- لم يتم حذف أي شيء. يوضح `code` السبب: `in_filed_report` عندما يتضمن التحديد شخصاً في تقرير تنظيمي نهائي، و`subject_deletion_in_progress` عندما يكون هناك طلب آخر لا يزال يحذف أحد الأشخاص المحددين. أعد المحاولة بعد انتهاء عملية الحذف تلك. content: application/json: schema: oneOf: - $ref: '#/components/schemas/InFiledReportError' - $ref: '#/components/schemas/SubjectDeletionInProgressError' '429': description: >- تم تجاوز حد المعدل؛ تراجع مؤقتاً وأعد المحاولة بعد الفاصل الزمني الموضح في `Retry-After`. content: application/json: examples: Rate limited: value: detail: Request was throttled. Expected available in 30 seconds. '503': description: >- كان مخزن البيانات البيومترية غير متاح أثناء الاحتفاظ بالقالب البيومتري أو مسحه. لم يُحذف أي شيء؛ كرر نفس الطلب. عمليات إعادة المحاولة تمتاز بخاصية idempotency وتلتقي عند قالب واحد. content: application/json: schema: type: object properties: detail: type: string examples: Retryable: value: detail: >- The biometric-template operation could not finish because an external store is unavailable. The operation is retryable. security: - ApiKeyAuth: [] x-codeSamples: - lang: curl label: curl source: |- 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-123", "user-456"]}' - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.users.batch_delete( vendor_data_list=["user-123", "user-456"], ) 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.users.batchDelete({ vendor_data_list: ["user-123", "user-456"], }); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Users.BatchDelete(ctx, didit.UsersBatchDeleteParams{\n\tVendorDataList: didit.Some([]string{\"user-123\", \"user-456\"}),\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)" - lang: java label: Java source: >- import java.util.List; import me.didit.Didit; import me.didit.types.UsersBatchDeleteParams; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.users().batchDelete(UsersBatchDeleteParams.builder() .vendorDataList(List.of("user-123", "user-456")) .build()); System.out.println(result); - lang: php label: PHP source: |- users->batchDelete([ 'vendor_data_list' => ['user-123', 'user-456'], ]); print_r($result->toArray()); - lang: ruby label: Ruby source: >- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.users.batch_delete(vendor_data_list: ["user-123", "user-456"]) puts result.to_h - lang: csharp label: .NET source: >- using System; using System.Text.Json; using Didit; // Reads DIDIT_API_KEY. using var client = new DiditClient(); var result = await client.Users.BatchDeleteAsync(new UsersBatchDeleteParams { VendorDataList = new string[] { "user-123", "user-456" }, }); Console.WriteLine(JsonSerializer.Serialize(result)); components: schemas: InFiledReportError: type: object description: >- رُفض الحذف لأن البيانات المحددة مدرجة في تقرير تنظيمي نهائي. لم يُحذف أي شيء. احذف التقرير، ثم كرر الطلب. required: - detail - code properties: detail: type: string code: type: string enum: - in_filed_report description: رمز خطأ ثابت لعملية حذف محظورة بسبب تقرير تنظيمي نهائي. reports: type: array items: $ref: '#/components/schemas/FiledRegulatoryReport' description: التقارير التي تمنع حذف شخص أو شركة أو حالة أو جلسة. transactions: type: array items: $ref: '#/components/schemas/FiledReportTransaction' description: المعاملات التي تمنع حذف المعاملة، مع التقارير التي تدرج كل منها. SubjectDeletionInProgressError: type: object description: >- لا يزال هناك طلب آخر يحذف هذا الشخص أو هذه الشركة. لم يحذف هذا الطلب أي شيء ويمكن إعادته بمجرد انتهاء ذلك الحذف؛ وعند تكراره يتم حذف كل ما لا يزال محدداً. required: - detail - code properties: detail: type: string code: type: string enum: - subject_deletion_in_progress description: رمز خطأ ثابت لشخص أو شركة لا يزال طلب آخر يحذفهما. FiledRegulatoryReport: type: object description: تقرير تنظيمي مكتمل يمنع الحذف المطلوب. required: - uuid - report_number - report_type - case_uuid properties: uuid: type: string format: uuid description: معرّف UUID للتقرير. report_number: type: string description: رقم التقرير المعروض في Console (على سبيل المثال، SAR-0001). report_type: type: string enum: - SAR - STR - CTR - TTR - UTR - IFT - CBR - TFR description: نوع التقرير التنظيمي. case_uuid: type: string format: uuid description: الحالة التي ينتمي إليها التقرير. FiledReportTransaction: type: object description: معاملة لا يمكن حذفها لأن تقريراً تنظيمياً نهائياً يدرجها. required: - uuid - transaction_id - reports properties: uuid: type: string format: uuid description: معرّف UUID لمعاملة Didit. transaction_id: type: string description: معرّف المعاملة المقدَّم عند إنشاء المعاملة. reports: type: array items: $ref: '#/components/schemas/FiledRegulatoryReport' description: التقارير المكتملة التي تتضمن هذه المعاملة. securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- مفتاح API الخاص بتطبيقك، من Developers -> API keys في Business Console. يمتلك المفتاح الأساسي وصولاً كاملاً. يمكن تحديد نطاق المفتاح المسمى: لا شيء، أو قراءة، أو كتابة لكل مورد، ومحدوداً ببعض مسارات العمل أو بالجلسات المقبولة، وبقائمة من عناوين IP، وبتاريخ انتهاء الصلاحية. يشير 401 إلى أن المفتاح غير صحيح أو ملغى أو منتهي الصلاحية؛ ويشير 403 إلى أنه لم يتم إرسال أي مفتاح، أو أن المفتاح ليس لديه حق الوصول إلى هذا المورد أو الإجراء، أو أن الطلب جاء من عنوان خارج قائمة عناوين IP الخاصة به؛ ويشير 404 في مسار جلسة إلى أن الجلسة خارج مسارات العمل أو الحالات الخاصة بالمفتاح. يتلقى المفتاح الذي لا يمتلك حق الوصول إلى الوسائط عناوين URL للصور ومقاطع الفيديو وملفات PDF كـ null، ويتلقى المفتاح الذي لا يمتلك إذن كتابة للجلسات روابط الجلسة وtoken كـ null. راجع https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.