बैच उपयोगकर्ता हटाएँ API: GDPR इरेज़र

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"]}'

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);

ctx := context.Background()
// Reads DIDIT_API_KEY.
client := didit.NewClient()

result, err := client.Users.BatchDelete(ctx, didit.UsersBatchDeleteParams{
	VendorDataList: didit.Some([]string{"user-123", "user-456"}),
})
if err != nil {
	log.Fatal(err)
}
fmt.Printf("%+v\n", result)

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);

<?php

require 'vendor/autoload.php';

use Didit\DiditClient;

// Reads DIDIT_API_KEY.
$didit = new DiditClient();

$result = $didit->users->batchDelete([
    'vendor_data_list' => ['user-123', 'user-456'],
]);
print_r($result->toArray());

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));

{
  "deleted": 2
}

POST

users

delete

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"]}'

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);

ctx := context.Background()
// Reads DIDIT_API_KEY.
client := didit.NewClient()

result, err := client.Users.BatchDelete(ctx, didit.UsersBatchDeleteParams{
	VendorDataList: didit.Some([]string{"user-123", "user-456"}),
})
if err != nil {
	log.Fatal(err)
}
fmt.Printf("%+v\n", result)

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);

<?php

require 'vendor/autoload.php';

use Didit\DiditClient;

// Reads DIDIT_API_KEY.
$didit = new DiditClient();

$result = $didit->users->batchDelete([
    'vendor_data_list' => ['user-123', 'user-456'],
]);
print_r($result->toArray());

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));

{
  "deleted": 2
}

अवलोकन

एक या अधिक उपयोगकर्ता इकाइयाँ हटाता है। उपयोगकर्ता रिकॉर्ड स्थायी रूप से हटा दिए जाते हैं। उनके सत्यापन सत्र इस endpoint से कवर नहीं होते और उपयोगकर्ता से उनका जुड़ाव हटाकर बने रहते हैं। उन्हें सत्र हटाएँ या बैच में सत्र हटाएँ से हटाएँ। लेन-देन भी इसमें शामिल नहीं हैं; उन्हें बैच में लेन-देन हटाएँ से हटाएँ।

इसका उपयोग कब करें

भुलाए जाने के अधिकार से जुड़े अनुरोध (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 पर सेट नहीं करते, उपयोगकर्ता से जुड़े रखे गए बायोमेट्रिक टेम्पलेट उपयोगकर्ता हटाने से पहले साफ़ कर दिए जाते हैं। यदि किसी बायोमेट्रिक स्टोर के उपलब्ध न होने से टेम्पलेट साफ़ नहीं हो पाता, तो कॉल 503 लौटाती है, अनुरोध का कोई भी उपयोगकर्ता नहीं हटता, और उसी अनुरोध को दोहराने से काम पूरा हो जाता है।

अंतिम रूप दी गई नियामक रिपोर्ट में डेटा

यदि चुना गया कोई भी व्यक्ति ऐसे केस का हिस्सा है जिसकी अंतिम नियामक रिपोर्ट है, तो पूरा अनुरोध 409 लौटाता है और कुछ भी नहीं हटता। प्रतिक्रिया में code: in_filed_report होता है और हर रिपोर्ट का नाम होता है, ताकि आप उसे Console में खोल सकें:

{
  "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"
    }
  ]
}

रिपोर्ट हटाएँ से हर रिपोर्ट हटाएँ, फिर वही अनुरोध दोहराएँ। यदि चुना गया कोई और व्यक्ति अब भी किसी रिपोर्ट में है, तो केवल किसी एक व्यक्ति को सूची से हटाना पर्याप्त नहीं है।

पहले से चल रही हटाने की प्रक्रिया

किसी व्यक्ति को एक समय में केवल एक अनुरोध द्वारा हटाया जाता है। यदि कोई और अनुरोध चुने गए किसी व्यक्ति को अभी भी हटा रहा है, तो यह अनुरोध अधिकतम कुछ सेकंड प्रतीक्षा करता है, फिर code: subject_deletion_in_progress के साथ 409 लौटाता है और कुछ नहीं हटाता:

{
  "detail": "This person or company is being deleted. Retry after deletion completes.",
  "code": "subject_deletion_in_progress"
}

दूसरी हटाने की प्रक्रिया पूरी होने के बाद वही अनुरोध दोहराएँ। जिस व्यक्ति को वह पहले ही हटा चुका है, वह अब मेल नहीं खाता, इसलिए दोहराया गया अनुरोध केवल बचे हुए लोगों को हटाता है।

अनुमतियाँ

एप्लिकेशन की कोई भी सक्रिय API कुंजी इस endpoint को कॉल कर सकती है। Didit API कुंजियाँ एप्लिकेशन के दायरे तक सीमित हैं, भूमिका के दायरे तक नहीं: Console की भूमिकाएँ और अनुमतियाँ (delete:users और बाकी) तय करती हैं कि कोई व्यक्ति Console में क्या कर सकता है, और Management API ट्रैफ़िक के लिए इनका मूल्यांकन नहीं होता। इस endpoint को कौन कॉल कर सकता है, इसे यह नियंत्रित करके तय करें कि एप्लिकेशन की API कुंजी कौन पढ़ सकता है।

आपकी एप्लिकेशन की 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।

बॉडी

application/json

vendor_data_list, didit_internal_id_list, या delete_all: true प्रदान करें। दोनों सूचियों को जोड़ा जा सकता है और वे OR से जुड़ी होती हैं। जब delete_all true होता है तो यह प्राथमिकता लेता है और दोनों सूचियों को अनदेखा कर दिया जाता है।

vendor_data_list

string[]

हटाने के लिए आपके अपने पहचानकर्ता, ठीक वैसे ही मिलान किए जाते हैं जैसे भेजे गए थे।

didit_internal_id_list

string<uuid>[]

हटाने के लिए Didit आंतरिक उपयोगकर्ता IDs - create और get endpoints द्वारा लौटाई गई didit_internal_id।

delete_all

boolean

डिफ़ॉल्ट:false

यदि true है, तो एप्लिकेशन में प्रत्येक उपयोगकर्ता को हटा देता है।

retain_face_embeddings

boolean

डिफ़ॉल्ट:false

डुप्लिकेट डिटेक्शन के लिए प्रत्येक हटाए गए व्यक्ति के एक छवि-मुक्त बायोमेट्रिक टेम्पलेट को face_retention_days के लिए रखने का आपका स्पष्ट विकल्प। व्यक्ति के बारे में बाकी सब कुछ हटा दिया जाता है। उपयोगकर्ताओं के साथ टेम्पलेट हटाने के लिए इसे छोड़ दें, या false भेजें। true होने पर, face_retention_days आवश्यक है।

face_retention_days

integer

छवि-मुक्त बायोमेट्रिक टेम्पलेट को रखे जाने वाले दिनों की संख्या जब retain_face_embeddings का मान true हो। इसके साथ आवश्यक है, और इसके बिना face_retention_days पर 400 के साथ अस्वीकृत कर दिया जाता है।

आवश्यक सीमा: 1 <= x <= 3650

उदाहरण:

365

प्रतिक्रिया

उपयोगकर्ता हटाए गए। वास्तव में हटाए गए उपयोगकर्ताओं की संख्या लौटाता है।

deleted

integer

हटाए गए उपयोगकर्ताओं की संख्या (vendor_data मानों को बाहर करता है जो किसी भी चीज़ से मेल नहीं खाते थे)।

अंतिम संशोधन 7 नवंबर 2026

​अवलोकन

​इसका उपयोग कब करें

​टिप्पणियाँ

​अंतिम रूप दी गई नियामक रिपोर्ट में डेटा

​पहले से चल रही हटाने की प्रक्रिया

​अनुमतियाँ

​संबंधित

प्राधिकरण