> ## 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/hi/entities/users/overview.md) हटाता है। उपयोगकर्ता रिकॉर्ड स्थायी रूप से हटा दिए जाते हैं। उनके सत्यापन सत्र इस endpoint से कवर नहीं होते और उपयोगकर्ता से उनका जुड़ाव हटाकर बने रहते हैं। उन्हें [सत्र हटाएँ](https://docs.didit.me/hi/sessions-api/delete-session.md) या [बैच में सत्र हटाएँ](https://docs.didit.me/hi/management-api/sessions/batch-delete.md) से हटाएँ। लेन-देन भी इसमें शामिल नहीं हैं; उन्हें [बैच में लेन-देन हटाएँ](https://docs.didit.me/hi/management-api/transactions/delete.md) से हटाएँ।## इसका उपयोग कब करें- **भुलाए जाने के अधिकार** से जुड़े अनुरोध (GDPR / CCPA)। - QA के दौरान परीक्षण उपयोगकर्ताओं की **सफ़ाई**। - अपने प्लेटफ़ॉर्म से हटाए गए उपयोगकर्ताओं का **प्रावधान हटाना**।## टिप्पणियाँ- `vendor_data` मानों की सूची, `didit_internal_id` मानों की सूची, या `delete_all: true` स्वीकार करता है। दोनों सूचियों को मिलाया जा सकता है और वे OR के रूप में जोड़ी जाती हैं। - यह endpoint `delete_all` को फ़िल्टर से कभी सीमित नहीं करता, और Console के `filter_*` बैच पैरामीटर `400` के साथ अस्वीकार किए जाते हैं, इसलिए सीमित इरादा एप्लिकेशन के हर उपयोगकर्ता को नहीं हटाता। अपवाद `filter_has_approved_sessions` और `filter_has_declined_sessions` हैं: इन्हें न तो अस्वीकार किया जाता है और न लागू किया जाता है, इसलिए इन्हें `delete_all` के साथ न भेजें। - सब कुछ या कुछ नहीं: यदि चुने गए उपयोगकर्ताओं के लिए हटाना पूरा नहीं हो सकता, तो उनमें से कोई भी नहीं हटता, और आप उसी अनुरोध को सुरक्षित रूप से दोहरा सकते हैं। - आइडेम्पोटेंट: उसी सूची को दोबारा भेजने पर पहली बार के बाद `deleted: 0` लौटता है। - यह केवल हटाए गए आइटमों की संख्या लौटाता है, प्रति-आइटम रिपोर्ट नहीं। जो मान किसी से मेल नहीं खाए, उन्हें चुपचाप छोड़ दिया जाता है। यदि आप `deleted` की तुलना उन पहचानकर्ताओं की संख्या से करना चाहते हैं जो आपने भेजे, तो डुप्लिकेट-रहित सूची भेजें, क्योंकि दोहराया गया पहचानकर्ता केवल एक बार गिना जाता है। - हटाने के लिए कोई webhook नहीं भेजा जाता। webhook उपयोगकर्ता की स्थिति और डेटा में बदलाव पर ट्रिगर होते हैं, हटाने पर नहीं, इसलिए जिस इंटीग्रेशन को हटाने का संकेत चाहिए, उसे यह अपनी ओर से दर्ज करना होगा। - उपयोगकर्ता से जुड़े सत्यापन सत्र इस endpoint से नहीं हटाए जाते। वे उपयोगकर्ता से जुड़ाव हटाकर बने रहते हैं, इसलिए उनके दस्तावेज़, चेहरे और मीडिया तभी हटते हैं जब आप सत्रों को स्वयं हटाते हैं। - `retain_face_embeddings` (बूलियन, डिफ़ॉल्ट `false`) और `face_retention_days` (1 से 3650) हटाए गए हर व्यक्ति के लिए एक बिना इमेज वाला बायोमेट्रिक टेम्पलेट रखने का आपका स्पष्ट चुनाव हैं, जो डुप्लिकेट पहचान के लिए उतने दिनों तक रहेगा। व्यक्ति के बारे में और कुछ नहीं रखा जाता। दोनों को छोड़ दें ताकि टेम्पलेट उपयोगकर्ताओं के साथ हटा दिए जाएँ। `face_retention_days` बिना `retain_face_embeddings: true` के, या `retain_face_embeddings: true` बिना `face_retention_days` के दिया गया हो, तो `face_retention_days` पर `400` लौटता है। - जब तक आप `retain_face_embeddings` को `true` पर सेट नहीं करते, उपयोगकर्ता से जुड़े रखे गए [बायोमेट्रिक टेम्पलेट](https://docs.didit.me/hi/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/hi/management-api/regulatory-reports/delete.md) से हर रिपोर्ट हटाएँ, फिर वही अनुरोध दोहराएँ। यदि चुना गया कोई और व्यक्ति अब भी किसी रिपोर्ट में है, तो केवल किसी एक व्यक्ति को सूची से हटाना पर्याप्त नहीं है।## पहले से चल रही हटाने की प्रक्रियाकिसी व्यक्ति को एक समय में केवल एक अनुरोध द्वारा हटाया जाता है। यदि कोई और अनुरोध चुने गए किसी व्यक्ति को अभी भी हटा रहा है, तो यह अनुरोध अधिकतम कुछ सेकंड प्रतीक्षा करता है, फिर `code: subject_deletion_in_progress` के साथ `409` लौटाता है और कुछ नहीं हटाता:```json theme={null} { "detail": "This person or company is being deleted. Retry after deletion completes.", "code": "subject_deletion_in_progress" } ```दूसरी हटाने की प्रक्रिया पूरी होने के बाद वही अनुरोध दोहराएँ। जिस व्यक्ति को वह पहले ही हटा चुका है, वह अब मेल नहीं खाता, इसलिए दोहराया गया अनुरोध केवल बचे हुए लोगों को हटाता है।## अनुमतियाँएप्लिकेशन की कोई भी सक्रिय API कुंजी इस endpoint को कॉल कर सकती है। Didit API कुंजियाँ **एप्लिकेशन के दायरे तक सीमित हैं, भूमिका के दायरे तक नहीं**: Console की [भूमिकाएँ और अनुमतियाँ](https://docs.didit.me/hi/console/roles-permissions.md) (`delete:users` और बाकी) तय करती हैं कि कोई *व्यक्ति* Console में क्या कर सकता है, और Management API ट्रैफ़िक के लिए इनका मूल्यांकन नहीं होता। इस endpoint को कौन कॉल कर सकता है, इसे यह नियंत्रित करके तय करें कि एप्लिकेशन की API कुंजी कौन पढ़ सकता है।## संबंधित- [डेटा प्रतिधारण](https://docs.didit.me/hi/console/data-retention.md) - [ऑडिट लॉग](https://docs.didit.me/hi/console/audit-logs.md) - [उपयोगकर्ता संचालन](https://docs.didit.me/hi/entities/users/operations.md) - [बायोमेट्रिक टेम्पलेट](https://docs.didit.me/hi/management-api/biometric-templates/overview.md) ## OpenAPI ````yaml hi/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: >- उपयोगकर्ताओं को **स्थायी रूप से हटाएं**: उपयोगकर्ता रिकॉर्ड स्थायी रूप से हटा दिए जाते हैं। सामान्य ब्लॉक करने के लिए `BLOCKED` के साथ [उपयोगकर्ता स्थिति अपडेट करें](#patch-/v3/users/-vendor_data-/update-status/) को प्राथमिकता दें। `vendor_data_list` के साथ, `didit_internal_id_list` के साथ, या दोनों के साथ एक साथ उपयोगकर्ताओं का चयन करें; या `delete_all: true` पास करें। यह endpoint कभी भी फ़िल्टर के साथ `delete_all` को सीमित नहीं करता है। कंसोल के People फ़िल्टर `400` के साथ अस्वीकार कर दिए जाते हैं (`400` रिस्पॉन्स देखें), ताकि सीमित किया गया इरादा पूर्ण वाइप में न बदल जाए। दो अपवाद: `filter_has_approved_sessions` और `filter_has_declined_sessions` अस्वीकार नहीं किए जाते हैं और लागू नहीं किए जाते हैं, इसलिए `delete_all: true` के साथ वे अभी भी प्रत्येक उपयोगकर्ता को हटाते हैं; उन्हें न भेजें। **बायोमेट्रिक टेम्पलेट:** जब तक कि आप `retain_face_embeddings` को `true` पर सेट नहीं करते हैं, सत्र हटाने के बाद इन उपयोगकर्ताओं के लिए रखे गए प्रत्येक छवि-मुक्त बायोमेट्रिक टेम्पलेट (देखें `/v3/biometric-templates/`) को उपयोगकर्ता हटाए जाने से पहले पर्ज कर दिया जाता है, जिससे वह व्यक्ति डुप्लिकेट पहचान और चेहरा खोज में मेल खाना बंद कर देता है। `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 आंतरिक उपयोगकर्ता IDs - create और get endpoints द्वारा लौटाई गई `didit_internal_id`। 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` हो। इसके साथ आवश्यक है, और इसके बिना `face_retention_days` पर `400` के साथ अस्वीकृत कर दिया जाता है। 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."` के साथ अस्वीकार कर दिया जाता है। केवल-कंसोल फ़िल्टर (`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: >- कोई क्रेडेंशियल प्रदान नहीं किए गए। `x-api-key` हेडर (या `Authorization: Bearer` token) के बिना `/v3/users/*` पाथ पर आने वाले अनुरोधों को 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: >- बायोमेट्रिक टेम्पलेट को बनाए रखने या हटाने के दौरान एक बायोमेट्रिक स्टोर अनुपलब्ध था। कुछ भी हटाया नहीं गया है; वही अनुरोध दोहराएं। पुनः प्रयास आइडेम्पोटेंट होते हैं और एक ही टेम्पलेट पर कन्वर्ज होते हैं। 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: कंसोल में दिखाई गई रिपोर्ट संख्या (उदाहरण के लिए, 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: Didit लेन-देन UUID। 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 कुंजी, Business Console में Developers -> API keys से। प्राथमिक कुंजी के पास पूर्ण एक्सेस होता है। एक नामित कुंजी को स्कोप किया जा सकता है: प्रति संसाधन none, read या write, कुछ वर्कफ़्लो या स्वीकृत सत्रों तक सीमित, IP पतों की सूची तक सीमित, और समाप्ति तिथि तक सीमित। 401 का अर्थ है कि कुंजी गलत है, निरस्त कर दी गई है या उसकी समय-सीमा समाप्त हो गई है; 403 का अर्थ है कि कोई कुंजी नहीं भेजी गई थी, कुंजी के पास इस संसाधन या कार्रवाई का एक्सेस नहीं है, या अनुरोध उसकी IP सूची से बाहर के पते से आया था; सत्र रूट पर 404 का अर्थ है कि सत्र कुंजी के वर्कफ़्लो या स्थितियों से बाहर है। मीडिया एक्सेस के बिना एक कुंजी को छवि, वीडियो और PDF URL null के रूप में प्राप्त होते हैं, और सत्र write के बिना एक कुंजी को सत्र लिंक और token null के रूप में प्राप्त होते हैं। देखें https://docs.didit.me/console/api-keys। ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.