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

دعم KYC وKYB

يُنشئ endpoint واحد جلسات التحقق من المستخدمين والتحقق من الشركات. يحدد نوع سير العمل نوع الجلسة:
  • إذا مرّرت workflow_id لـ سير عمل KYC، تُنشأ جلسة التحقق من المستخدمين (KYC). تكون قيمة الاستجابة session_kind: "user".
  • إذا مرّرت workflow_id لسير عمل KYB، تُنشأ جلسة التحقق من الشركات (KYB). تكون قيمة الاستجابة session_kind: "business".
يمكنك إعداد سير العمل من لوحة التحكم عبر Workflows → Create workflow. يكون سير العمل إما KYC أو KYB وقت إنشائه، ولا يمكنك تغيير نوعه لاحقًا.

الأمثلة

الاستجابة (201 Created):

مستندات التوقيع الإلكتروني

عندما يحتوي سير العمل على خطوة التوقيع الإلكتروني تأخذ المستندات من الجلسة (أي عند ضبط signature_documents_source على session أو both)، أرسلها في sign.documents. كل مستند هو الملف بترميز base64، حتى لا يحتاج Didit أبدًا إلى جلبه من عنوان URL.
إذا لم تُرسل fields، يقرأ الموقّع المستند ويوافق عليه.

وضع الحقول بحسب نص anchor

بدلًا من الموضع، يمكن أن يحمل الحقل anchor: مقطع نصي في المستند يحدد مكان وضع الحقل. تناسب المراسي المستندات التي تُنشأ لكل جلسة، مثل المستندات المولَّدة من قالب Word. أما مستندات سير العمل فضَع حقولها في لوحة التحكم. إذا لم يكن النص موجودًا في المستند، يعيد الاستدعاء 400 مع field_anchor_not_found ومفتاح الحقل. لا يزيل Didit نص المرساة من ملف PDF، لذلك اكتبه بلون مطابق للون خلفية الصفحة.

قيم الحقول

يضبط sign.field_values قيمة كل حقل يكون prefill فيه هو api.<key>، سواء في مستندات سير العمل أو في مستندات الجلسة. وهو كائن تكون مفاتيحه أسماء <key> تلك. القيم نصوص من 1 إلى 500 حرف لحقول text وdata، وقيم منطقية لحقل checkbox.

الأخطاء والاستدعاءات المتكررة

تقبل الجلسة 20 مستندًا كحد أقصى بإجمالي 50 ميغابايت. يعيد الاستدعاء 400 مع خطأ sign في الحالات التالية:
  • لا يحتوي سير العمل على خطوة التوقيع الإلكتروني.
  • أرسلت sign.documents بينما تأخذ الخطوة مستندات سير العمل فقط.
  • تأخذ الخطوة مستندات الجلسة فقط ولم ترسل أيًا منها، أو لا تحتوي على مستندات سير العمل ولم ترسل أيًا منها.
  • المستند أكبر من الحد المسموح، أو ليس بترميز base64 صالح، أو ليس من نوع ملف مدعوم.
  • يُرفض ملف Word مع signature_document_not_supported، أو يتعذر تحويله فيعيد signature_document_conversion_failed، مع كل reason مذكور في الملفات المدعومة.
  • حقل غير صالح، أو لم يُعثر على المرساة (field_anchor_not_found)، أو تُرفض قيمة حقل.
تكرار استدعاء الإنشاء للقيمتين workflow_id وvendor_data نفسيهما يعيد الجلسة قيد الانتظار. وإذا أرسل هذا الاستدعاء sign، فيجب أن تكون مستنداته وحقوله وقيم حقوله مطابقة تمامًا للأولى (بالترتيب نفسه والعناوين وأسماء الملفات والمحتوى والحقول والقيم). وأي اختلاف يعيد 400 مع {"sign": "signature_document_changed"}: استخدم vendor_data مختلفًا، أو انتظر حتى تنتهي الجلسة قيد الانتظار.

الاختبار باستخدام سيناريوهات البيئة التجريبية

في تطبيق يعمل في البيئة التجريبية، مرّر sandbox_scenario لتحميل نتيجة محددة مسبقًا (قبول، أو رفض بعينه، أو سيناريو قيد المراجعة) دون المساس بالمزودين الحقيقيين أو برصيدك:
يُرفض sandbox_scenario بالخطأ 400 في تطبيقات الإنتاج. إذا لم تكن تعرف النتيجة وقت الإنشاء، فـفعّلها (أو أعد تفعيلها) لاحقًا عبر POST /v3/session/{session_id}/sandbox/arm/، طالما ما زالت الجلسة في حالة Not Started: يستخدم منتقي السيناريو في تدفق الصفحة المستضافة قبل بدء التحقق نقطة النهاية نفسها. راجع البيئة التجريبية وبيانات الاختبار للاطلاع على كتالوج السيناريوهات الكامل، وسجل القيم السحرية، وبنية الطلب والاستجابة لـ endpoint التفعيل.

يربط vendor_data الجلسة بكيان

  • في سير عمل KYC: يُربط بـكيان المستخدم. إذا لم يكن المستخدم موجودًا، يُنشأ تلقائيًا.
  • في سير عمل KYB: يُربط بـكيان الشركة. يُنشأ تلقائيًا إذا كان جديدًا.
لمزيد من التفاصيل، راجع ربط بيانات المورّد.

الموافقة البيومترية في إلينوي وتكساس وكولورادو

يمكن للتدفق المستضاف وحزمة SDK الأصلية الإصدار 4.10.0 أو أحدث أن يعرضا خطوة موافقة بيومترية صريحة قبل أول التقاط للوجه، وذلك حسب وضع الموافقة في تطبيقك ومكان وجود الشخص. يُدخل حقلان اختياريان في هذا القرار:
  • user_state: مكان إقامة الشخص، عندما تعرفه (US-IL أو IL أو Illinois). في الوضع التلقائي (Auto)، تجعل الولاية المشمولة التدفق يطلب الموافقة.
  • biometric_consent: كائن يحتوي على given_at وtext_version، للموافقة التي جمعتها بالفعل. لن يطلب التدفق الموافقة مرة أخرى.
لا تستطيع حزم SDK الأصلية التي تقل عن الإصدار 4.10.0 عرض هذه الخطوة. تعمل جلساتها كما كانت من قبل، ويُبلغ القرار بأن الموافقة لم تُجمع. راجع الموافقة البيومترية.

مهم: الإفصاح والموافقة ما زالا يتمّان في منتجك

تُنشئ Create Session رابط التحقق و token الجلسة. لكنها لا تثبت بحد ذاتها أنك عرضت على المستخدم الإفصاحات أو حصلت على الموافقة المطلوبة لحالة الاستخدام الخاصة بك. إذا بدأت جلسة Didit من تطبيقك أو موقعك أو غلاف SDK لديك أو تدفق العلامة البيضاء، فينبغي أن تتولى الجانب القانوني في تجربة المستخدم لديك قبل أن يبدأ المستخدم التقاط البيانات.

قائمة التحقق المسبق الموصى بها

  1. أخبر المستخدم بأن شركتك هي من تطلب التحقق، وأن Didit هي مزود التحقق ومعالج البيانات الذي يشغّل التدفق.
  2. اربط بـ إشعار الخصوصية الخاص بك وأي شروط قانونية خاصة بالجهة المتحكِّمة وتنطبق على هذا المسار.
  3. اربط بـ إشعار خصوصية التحقق وشروط المستخدم النهائي للتحقق من الهوية الخاصين بـ Didit.
  4. إذا تضمّن سير عملك التقاط المستند أو التقاط صورة السيلفي أو كشف الحيوية أو القياسات البيومترية، فاجمع موافقة صريحة وإيجابية حيثما يتطلب ذلك القانون المعمول به أو موقفك القانوني.
  5. إذا كنت تستخدم واجهة مخصصة أو نطاقًا مخصصًا أو مسارًا يعتمد على API فقط، فاعرض هذه الإفصاحات في منتجك قبل توجيه المستخدم إلى تدفق Didit.
  6. احتفظ بسجلك الخاص لنص الإشعار والموافقة وطابعها الزمني والبيانات الوصفية المرتبطة بهما، إذا اشترط فريقك القانوني وجود سجل تدقيق.
تختلف المتطلبات القانونية باختلاف الولاية القضائية. لا تُلغي العلامة البيضاء دور Didit في تدفق التحقق. راجِع تطبيقك مع مستشار قانوني قبل الإطلاق إذا كنت تعمل في ولايات قضائية تطبّق قواعد خاصة بالقياسات البيومترية.

التفويضات

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
workflow_id
string<uuid>
مطلوب

معرّف ثابت لسير العمل الذي يحدد خطوات التحقق التي ستشغلها الجلسة. يتم إنشاء مسارات العمل وإدارتها في صفحة مسارات العمل في Console. يحدد workflow_id أيضاً بشكل ضمني ما إذا كانت الجلسة مخصصة لـ KYC أو KYB.

مثال:

"11111111-2222-3333-4444-555555555555"

vendor_data
string

معرّف فريد للمستخدم الذي يتم التحقق منه، مثل UUID أو بريد إلكتروني أو معرّف مستخدم داخلي. يُستخدم هذا الحقل من أجل: (1) تجميع المستخدمين — يتم ربط الجلسات التي تحتوي على نفس vendor_data بنفس الملف التعريفي للمستخدم في تبويب Users. (2) اكتشاف التكرار عبر الجلسات — عند التحقق من تكرار الوجوه أو المستندات أو أرقام الهواتف أو رسائل البريد الإلكتروني أو عناوين IP أو بصمات الأجهزة، تُعامل الجلسات التي تحتوي على نفس vendor_data على أنها للمستخدم نفسه ويتم استبعادها من التطابقات. بدون vendor_data، تُعامل كل جلسة كمستخدم فريد وتظهر جميع حالات التكرار المحتملة. نوصي بشدة بتقديم vendor_data دائمًا لتقليل التشويش في اكتشاف التكرار.

مثال:

"user-123"

multi_account_segment
string

نطاق اختياري لكشف التكرار داخل مؤسستك. تقارن عمليات فحص تكرار الوجوه هذه الجلسة فقط بالجلسات الأخرى التي تحمل نفس الشريحة، بحيث لا تؤدي قواعد الحسابات المنفصلة (الحسابات الشخصية وحسابات الشركات، أو حساب واحد لكل عميل فرعي B2B) إلى الإبلاغ عن شخص يمتلك حساباً واحداً في كل منها بشكل مشروع. اتركه فارغاً لاستخدام النطاق الافتراضي الموحد، وهو ما تستخدمه كل جلسة حالياً. تتجاهل مطابقة قائمة الحظر وقائمة السماح هذا الحقل.

Maximum string length: 64
مثال:

"business-accounts"

callback
string

رابط URL لإعادة توجيه المستخدم إليه بعد اكتمال التحقق. يُلحق Didit تلقائياً verificationSessionId وstatus (Approved، Declined، In Review) كمعاملات استعلام. مخططات URL المخصصة (مثل myapp://) مدعومة لعمليات الاستدعاء على الأجهزة المحمولة. إذا حُذف، يُستخدم callback_url الافتراضي لسير العمل. عندما يحتوي التطبيق على نطاقات مسموح بها (allowed_domains في PATCH /v3/webhook/)، يجب أن يكون استدعاء http أو https على أحد تلك الأصول (نفس المخطط والمضيف والمنفذ)، وإلا سيفشل الطلب برمز 400 على callback: callback must be on one of the application's allowed domains: https://app.example.com. تُقبل دائماً مخططات URL المخصصة.

مثال:

"https://example.com/verification/callback"

callback_method
enum<string>
افتراضي:initiator

يحدد الجهاز الذي يجب أن يتعامل مع إعادة التوجيه إلى رابط الاستدعاء المقدم. استخدم initiator لإعادة توجيه الجهاز الذي بدأ سير العمل فقط، أو completer للجهاز الذي ينهيه، أو both للسماح لأي من الجهازين بتشغيل الاستدعاء. إذا لاحظت في أي وقت أن الاستدعاء لا يعمل بشكل موثوق، نوصي بتعيين هذه القيمة على both.

الخيارات المتاحة:
initiator,
completer,
both
مثال:

"both"

metadata
any

بيانات JSON عشوائية مخزنة مع الجلسة ويتم إرجاعها في الاستجابة وأحداث webhook. يتم قبول أي قيمة JSON (كائن، نص، رقم، مصفوفة)، ولكن يُوصى باستخدام كائن JSON لأزواج المفاتيح/القيم. لا تظهر للمستخدم النهائي. استخدمها لتمرير معرّفات الارتباط الخاصة بك، أو متغيرات اختبار A/B، أو سياق العمل.

مثال:
tags
string[]

العلامات المضافة إلى الجلسة عند إنشائها، بالاسم. ما يصل إلى 10، كل منها بحد أقصى 50 حرفاً. الأسماء غير حساسة لحالة الأحرف وتُخزّن بأحرف كبيرة. يتم إنشاء الاسم الذي ليس له وجود بعد في التطبيق كعلامة جديدة. تظهر العلامات على الجلسة في لوحة التحكم، حيث يمكنك التصفية بناءً عليها.

Maximum array length: 10
Maximum string length: 50
مثال:
language
enum<string>

رمز اللغة (ISO 639-1) لواجهة عملية التحقق. يتحكم في اللغة المعروضة للمستخدم النهائي أثناء التحقق. إذا لم يتم توفيره، فسيتم اكتشاف لغة المتصفح واستخدامها تلقائياً. تحقق من جميع اللغات المدعومة هنا.

الخيارات المتاحة:
en,
ar,
bg,
bn,
bs,
ca,
cnr,
cs,
da,
de,
el,
es,
et,
fa,
fi,
fr,
he,
hi,
hr,
hu,
hy,
id,
it,
ja,
ka,
kk,
ko,
ky,
lt,
lv,
mk,
mn,
ms,
nl,
no,
pl,
pt-BR,
pt,
ro,
ru,
sk,
sl,
so,
sq,
sr,
sv,
th,
tr,
uk,
uz,
vi,
zh-CN,
zh-TW,
zh
مثال:

"en"

contact_details
object

معلومات الاتصال الخاصة بالمستخدم التي يمكن استخدامها للإشعارات، وملء نماذج التحقق مسبقاً، والتحقق من رقم الهاتف. يتضمن ذلك عنوان البريد الإلكتروني، واللغة المفضلة للتواصل، ورقم الهاتف.

مثال:
expected_details
object

تفاصيل المستخدم المتوقعة المُستخدمة للتحقق المتبادل مقابل البيانات المستخرجة من مستند التحقق من الهوية الخاص بالمستخدم، وإثبات العنوان، وخطوات التحقق الأخرى. تظهر حالات عدم التطابق كتحذيرات في القرار؛ كما تؤدي بعض الحقول (مثل id_country وexpected_document_types) أيضاً إلى تعديل سير العمل الموجه للمستخدم. بالنسبة لسير عمل التحقق من الشركات (KYB)، تُستخدم حقول الشركة فقط (company_name وregistry_country وregistration_number) — حيث تملأ مسبقاً البحث في سجل الشركات للمستخدم — ويتم تجاهل جميع الحقول على مستوى الشخص.

مثال:
portrait_image
string<byte>

صورة شخصية لوجه المستخدم النهائي بترميز Base64 (بحد أقصى 2 ميغابايت؛ بصيغة JPEG أو PNG أو WebP أو TIFF). تُستخدم كصورة مرجعية لمطابقتها مع لقطة كشف الحيوية عندما يكون سير العمل عبارة عن سير عمل Biometric Authentication مع تفعيل مطابقة الوجه، أو أي سير عمل مخطط يتم فيه تشغيل مطابقة الوجه قبل التحقق من الهوية (OCR). اختيارية عندما يكون لدى مستخدم vendor_data صورة وجه مخزنة بالفعل: تعيد Didit استخدامها تلقائياً، وفقاً لترتيب الأولوية التالي: وجه من جلسة كشف حيوية مقبولة، صورة شريحة جواز السفر الإلكتروني، الصورة الشخصية في مستند الهوية، وجه الملف الشخصي المُسجّل يدوياً (يُعاد فقط استخدام الوجوه المأخوذة من جلسات مقبولة أو الوجوه التي سجّلتها بنفسك). عند تقديمها، تكون الأولوية دائماً لـ portrait_image على الوجه المخزن. في حال حذفها وعدم وجود وجه مخزن (أو عدم إرسال vendor_data)، يفشل إنشاء الجلسة بالرمز 400. يتم تجاهلها لأنواع سير العمل الأخرى.

مثال:

"iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII="

sandbox_scenario
string

معرّف سيناريو مخصص للبيئة التجريبية فقط. يُقبل فقط عندما ينتمي مفتاح API إلى تطبيق في وضع البيئة التجريبية؛ ويُرفض في تطبيقات بيئة الإنتاج. عند تعيينه، يُوسّع تدفق الإنشاء القيم السحرية المرفقة بالسيناريو لتُدرج في حقول إدخال الجلسة (contact_details، expected_details) حتى يُعيد المزودون المحاكون إنتاج نتيجة السيناريو من خلال مسار سير العمل الفعلي. راجع كتالوج السيناريوهات عبر GET /v1/sandbox/scenarios/ أو Sandbox & Test Data. يمكنك أيضاً تجهيز (أو إعادة تجهيز) سيناريو بعد الإنشاء عبر POST /v3/session/{sessionId}/sandbox/arm/، طالما أن الجلسة لا تزال بحالة Not Started. لعمليات البحث غير المعتمدة على المستندات، استخدم lookup_partial_match أو lookup_no_match أو lookup_provider_error لاختبار ميزانية المحاولات المهيأة والرجوع التلقائي. لمحفظات الهوية، استخدم wallet_cancelled أو wallet_timeout أو wallet_provider_error؛ بينما يُحاكي approve محفظة تم التحقق منها. يمكن اختبار جميع المحافظ المدرجة في الكتالوج داخل البيئة التجريبية، بما في ذلك المخططات غير المتاحة في تطبيقات بيئة الإنتاج. لا تُحتسب أي رسوم على المحاولات المحاكاة.

مثال:

"decline_document_expired"

sign
object

مدخلات التوقيع الإلكتروني لهذه الجلسة. documents هي المستندات المطلوب توقيعها، لسير عمل تتلقى فيه خطوة التوقيع الإلكتروني المستندات من الجلسة (signature_documents_source إما session أو both): بحد أقصى 20 مستنداً و50 ميغابايت إجمالاً. يملأ field_values الحقول التي يكون prefill الخاص بها هو api.<key>، في كل من مستندات سير العمل والجلسة على حد سواء. تؤدي إعادة إنشاء جلسة لنفس workflow_id وvendor_data إلى إرجاع الجلسة المعلقة؛ وإذا أرسل هذا الاستدعاء sign، فيجب أن تكون مستنداته وحقوله وقيمه مطابقة تماماً للمستندات والحقول والقيم الأولى، وأي اختلاف يُرجع 400 مع {"sign": "signature_document_changed"}. راجع مستندات التوقيع الإلكتروني.

user_state
string

مكان إقامة الشخص، عندما يكون معروفاً لديك: رمز قسم فرعي وفق معيار ISO 3166-2 (مثل US-IL، ES-M) أو رمز ولاية أمريكية أو اسمها (مثل IL، Illinois). الولاية التي يشترط قانونها الحصول على موافقة بيومترية صريحة (إلينوي، تكساس، كولورادو) تجعل سير عمل التحقق يطلبها قبل التقاط الوجه، مع المُشغِّل declared_state. تُرجع القيمة غير المعروفة الرمز 400. راجع الموافقة البيومترية.

Maximum string length: 16
مثال:

"US-IL"

الموافقة البيومترية الصريحة التي جمعتها بالفعل من الشخص. وهي تستوفي المتطلب، لذا لا يطلبها سير عمل التحقق مرة أخرى، ويسجلها القرار كـ status: "given" مع المُشغِّل customer_collected. لا يتم مطلقاً استبدال الإجابة التي قدمها الشخص بالفعل في سير العمل. راجع الموافقة البيومترية.

الاستجابة

تم إنشاء الجلسة (أو إرجاعها، إذا كانت هناك جلسة غير مكتملة بنفس قيمة vendor_data موجودة بالفعل في أحدث إصدار منشور من سير العمل). الاستجابة هي الجلسة المُسلسَلة، بما في ذلك عنوان url لصفحة التحقق المستضافة لإعادة توجيه المستخدم إليها.

session_id
string<uuid>
مطلوب

المعرّف الفريد لجلسة التحقق. استخدم هذا المعرّف عند استدعاء GET /v3/session/{sessionId}/decision/.

مثال:

"11111111-2222-3333-4444-555555555555"

session_number
integer
مطلوب

رقم تسلسلي ومقروء بوضوح يُعيّن للجلسة داخل تطبيقك. مفيد للدعم ولوحات التحكم.

مثال:

43762

session_token
string
مطلوب

رمز token آمن لعناوين URL مكوّن من 12 حرفاً يمنح المستخدم النهائي الإذن بالوصول إلى تدفق التحقق المستضاف على url. صالح حتى انتهاء صلاحية الجلسة. تعامل معه كسرٍ — يمكن لأي شخص يحمله فتح تدفق التحقق لهذه الجلسة.

مثال:

"3FaJ9wLqX2Mz"

url
string<uri>
مطلوب

رابط التحقق المستضاف لإعادة توجيه المستخدم النهائي إليه. يتضمن الرابط session_token، وإذا تم تكوينه، يستخدم نطاق العلامة البيضاء الخاص بك. عندما يتضمن الطلب language، يحتوي الرابط على جزء مسار اللغة — https://verify.didit.me/{language}/session/{session_token} (مثل /es/session/...)؛ وبدون language، يتم حذف هذا الجزء.

مثال:

"https://verify.didit.me/session/3FaJ9wLqX2Mz"

vendor_data
string | null
مطلوب

المعرّف الذي مرّرته في الطلب لربط الجلسة بمستخدم أو شركة في نظامك الخاص. يُعاد نصياً كما هو. ويكون Null عند عدم تقديمه.

مثال:

"user-123"

metadata
any
مطلوب

payload بصيغة JSON عشوائية قمت بتخزينها مع الجلسة وقت الإنشاء. يتم إرجاعها كما هي تماماً — أياً كانت قيمة JSON التي أرسلتها (كائن، نص، رقم، مصفوفة) يتم إرجاعها بحالتها، مع أنه يُوصى باستخدام كائن JSON. لا تظهر للمستخدم النهائي. تظهر دائماً في الاستجابات؛ وتكون null عند عدم تقديمها وقت الإنشاء.

مثال:
status
enum<string>
مطلوب

الحالة الحالية للجلسة. ترجع الجلسات المنشأة حديثاً الحالة Not Started. إذا كانت هناك جلسة غير مكتملة موجودة بالفعل لنفس vendor_data في أحدث إصدار منشور من سير العمل، فإن الحالة المرجعة تعكس تلك الجلسة الحالية.

الخيارات المتاحة:
Not Started,
In Progress,
Approved,
Declined,
In Review,
Expired,
Abandoned,
Kyc Expired,
Resubmitted,
Awaiting User
مثال:

"Not Started"

callback
string<uri> | null
مطلوب

رابط إعادة التوجيه النهائي الذي يُرسل إليه المستخدم بعد إكمال سير العمل. يلحق Didit المعاملين ?verificationSessionId={session_id}&status={status} بهذا الرابط. يتم الرجوع إلى رابط الاستدعاء المهيأ لسير العمل عند عدم تقديمه في الطلب؛ ويكون null إذا لم يتم تعيين أي منهما. عندما يحتوي التطبيق على نطاقات مسموح بها وكان هذا الرابط رابط ويب خارجها (على سبيل المثال، القيمة الافتراضية لسير العمل التي تم تعيينها قبل تغيير القائمة)، فإن سير العمل المستضاف لا يعيد توجيه المستخدم إليه.

مثال:

"https://example.com/verification/callback"

workflow_id
string<uuid>
مطلوب

معرّف ثابت لسير العمل الذي تعمل عليه هذه الجلسة. يكون دائماً معرّف المجموعة الثابت لسير العمل — حتى إذا أشرت إلى UUID لإصدار سير عمل محدد في الطلب (بحث متوافق مع الإصدارات السابقة)، فإن الاستجابة تحمل workflow_id الثابت. استخدمه لربط الجلسة بسير العمل الذي قمت بتهيئته في Console.

مثال:

"11111111-2222-3333-4444-555555555555"

workflow_version
integer
مطلوب

رقم إصدار سير العمل المنشور الذي تم تثبيت الجلسة عليه عند الإنشاء. تحل Didit قيمة workflow_id إلى أحدث إصدار منشور من سير العمل عند إنشاء الجلسة، وتستمر الجلسة في تشغيل هذا الإصدار حتى إذا أُعيد نشر سير العمل لاحقاً.

مثال:

3

tags
string[]

الوسوم الموجودة في الجلسة، حسب الاسم.

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