الانتقال إلى المحتوى الرئيسي
POST
curl

نظرة عامة

يفعّل أو يعطّل مراقبة AML المستمرة لـكيانات المستخدمين المحددة، تمامًا كما يعمل الإجراء AML Ongoing monitoring في Business Console. تنفّذ وحدة Console وهذا endpoint العملية الأساسية نفسها، لذلك تكون القواعد والفوترة والنتائج متطابقة. أرسل estimate_only: true أولًا لمعرفة عدد المستخدمين المحددين، وعدد من يحتاجون إلى فحص AML جديد، وتكلفة الفحص لمرة واحدة، وتكلفة المراقبة السنوية. لا يكتب التشغيل التجريبي أي بيانات.

متى تستخدمه

  • التسجيل البرمجي: فعّل المراقبة للمستخدمين الذين استوردتهم أو أنشأتهم عبر API دون إعادة فحصهم يدويًا.
  • إنهاء الخدمة: أوقف المراقبة، وتجديدها السنوي، للمستخدمين الذين غادروا منصتك.
  • التحكم في التكلفة: اطّلع على الأثر الدقيق للتكلفة لأي تحديد قبل اعتماده.

كيفية معالجة التحديد

  • فحص مراقب واحد لكل مستخدم. يُراقَب المستخدم الذي تحقق عدة مرات ويُفوتَر مرة واحدة. يؤدي التعطيل إلى إيقاف المراقبة عبر جميع فحوص هذا المستخدم.
  • يُفحص أولًا المستخدمون الذين لا يملكون فحص AML. تنشئ Didit تحقق AML جديدًا لهم (يظهر في تبويب Verifications لدى المستخدم)، ويُفوتَر كفحص AML عادي، وتُفعَّل عليه المراقبة. يتطلب ذلك الاسم الكامل وتاريخ الميلاد والدولة الخاصة بالمستخدم، ويُبلَّغ عن المستخدم الذي يفتقد أيًا منها بالقيمة skipped_no_identity_data بدلًا من تجاهله بصمت.
  • يُتخطى المستخدمون المحظورون (skipped_blocked). ولا تنشئ تطبيقات البيئة التجريبية أي فحوص أبدًا (skipped_sandbox).
  • يُتحقق من الرصيد مسبقًا. يُرفض التفعيل بالرمز 403 إذا لم يغطِّ رصيدك التقدير، وتتضمن الاستجابة التقدير حتى تعرف مقدار ما تحتاج إلى شحنه.
  • التجديد السنوي. يُفوتَر المستخدم المفعَّل حديثًا بسعر المراقبة السنوي عند تاريخ تجديده التالي، وهو التاريخ نفسه الذي تعرضه Console في عمود Ongoing monitoring. يوقف التعطيل التجديد، لكنه لا يسترد فترة سبق فوترتها.

التحديد وحجم الدفعة

حدِّد المستخدمين باستخدام vendor_data_list أو didit_internal_id_list أو كليهما؛ وتُدمَج القائمتان بعملية OR. يقبل الطلب ما لا يزيد على 1000 معرّف عبر القائمتين معًا. تُعاد المعرّفات التي لا تطابق أي مستخدم في تطبيقك ضمن unmatched كما أُرسلت تمامًا، ولا يفشل الطلب أبدًا: يكتمل التحديد الذي لا يطابق شيئًا كمهمة فارغة (total: 0) مع إدراج كل المعرّفات، وذلك وفق الاصطلاح نفسه المتبع في endpoints الخاصة بالحذف الدفعي.

المعالجة المباشرة أو في الخلفية

تُعالَج التحديدات التي تضم 20 مستخدمًا أو أقل مباشرة، ويعيد الاستدعاء الرمز 200 مع المهمة المكتملة. أما التحديدات الأكبر فتعيد الرمز 202 مع مهمة بحالة PENDING؛ استعلم عن الحصول على مهمة مراقبة AML حتى تصبح قيمة status إما COMPLETED أو FAILED. وفي الحالتين تتضمن المهمة إدخالًا واحدًا ضمن results لكل مستخدم مع outcome الخاص به.

webhooks

لا يُصدر تبديل المراقبة أي webhook خاص به. وبمجرد تفعيل المراقبة، تستمر عمليات إعادة الفحص في إطلاق أحداث status.updated وdata.updated المعتادة الموصوفة في مراقبة AML المستمرة.

الأذونات

يمكن لأي مفتاح API نشط للتطبيق استدعاء هذا endpoint. مفاتيح API في Didit محصورة بالتطبيق وليست بالأدوار: تحدد الأدوار والأذونات في Console ما يستطيع الشخص فعله داخل Console، ولا تُطبَّق على طلبات Management API.

ذات صلة

التفويضات

x-api-key
string
header
مطلوب

مفتاح API الخاص بتطبيقك، من Developers -> API keys في Business Console. يمتلك المفتاح الأساسي وصولاً كاملاً. يمكن تحديد نطاق المفتاح المسمى: لا شيء، أو قراءة، أو كتابة لكل مورد، ومحدوداً ببعض مسارات العمل أو بالجلسات المقبولة، وبقائمة من عناوين IP، وبتاريخ انتهاء الصلاحية. يشير 401 إلى أن المفتاح غير صحيح أو ملغى أو منتهي الصلاحية؛ ويشير 403 إلى أنه لم يتم إرسال أي مفتاح، أو أن المفتاح ليس لديه حق الوصول إلى هذا المورد أو الإجراء، أو أن الطلب جاء من عنوان خارج قائمة عناوين IP الخاصة به؛ ويشير 404 في مسار جلسة إلى أن الجلسة خارج مسارات العمل أو الحالات الخاصة بالمفتاح. يتلقى المفتاح الذي لا يمتلك حق الوصول إلى الوسائط عناوين URL للصور ومقاطع الفيديو وملفات PDF كـ null، ويتلقى المفتاح الذي لا يمتلك إذن كتابة للجلسات روابط الجلسة وtoken كـ null. راجع https://docs.didit.me/console/api-keys.

الجسم

application/json

حدد المستخدمين باستخدام vendor_data_list أو didit_internal_id_list أو كليهما (يتم الجمع بين القائمتين باستخدام المعامل OR). بحد أقصى 1000 معرّف لكل طلب عبر كلتا القائمتين.

is_enabled
boolean
مطلوب

true لتفعيل المراقبة، وfalse لتعطيلها.

estimate_only
boolean
افتراضي:false

عند التعيين على true، يُرجع تقدير التكلفة ولا ينفذ أي عمليات كتابة - لا فحص، ولا فوترة، ولا مهمة.

vendor_data_list
string[]

المعرّفات الخاصة بك للمستخدمين المراد تبديل حالتهم، وتتم مطابقتها تماماً كما أُرسلت.

didit_internal_id_list
string<uuid>[]

المعرّفات الداخلية لـ Didit للمستخدمين المراد تبديل حالتهم - أي didit_internal_id الذي تُرجعه endpoints الخاصة بالإنشاء والجلب والإدراج.

الاستجابة

التقدير (عندما يكون estimate_only صحيحاً) أو المهمة المكتملة لاختيار تمت معالجته بشكل مضمّن.

معاينة التكلفة. يتم إرجاعها مباشرة عندما يكون estimate_only صحيحاً (لا يتم كتابة أي شيء).

users_total
integer
مطلوب

الملفات الشخصية المطابقة للتحديد.

already_enabled
integer
مطلوب

الملفات الشخصية الخاضعة للمراقبة بالفعل (لا يلزم اتخاذ أي إجراء عند التفعيل؛ هذه هي الملفات التي يتم إيقافها عند التعطيل).

with_existing_aml
integer
مطلوب

الملفات الشخصية التي سيتم تحويل فحص AML الحالي الخاص بها إلى قيد المراقبة (دون إجراء فحص جديد).

needing_screening
integer
مطلوب

الملفات الشخصية التي لا تخضع لأي فحص AML وسيُجرى فحصها أولاً (تتم فوترتها كفحص AML عادي).

skipped_no_identity_data
integer
مطلوب

الملفات الشخصية التي لا يمكن فحصها بسبب نقص بيانات الهوية.

skipped_blocked
integer
مطلوب

المستخدمون المحظورون الذين سيتم تخطيهم (تكون دائماً 0 للشركات).

estimated_screening_cost_usd
number
مطلوب

التكلفة لمرة واحدة لعمليات الفحص الجديدة.

مثال:

0.2

estimated_annual_monitoring_cost_usd
number
مطلوب

تكلفة المراقبة السنوية للملفات الشخصية التي ستصبح خاضعة للمراقبة.

مثال:

0.07

balance_sufficient
boolean
مطلوب

ما إذا كان رصيد المؤسسة يغطي الفحص بالإضافة إلى السنة الأولى من المراقبة.

unmatched
string[]
مطلوب

معرّفات الطلب التي لم تطابق أي ملف تعريف في هذا التطبيق، تماماً كما أُرسلت.

آخر تعديل في ٧ نوفمبر ٢٠٢٦