الانتقال إلى المحتوى الرئيسي
ترسل webhooks التنبيهات تنبيهات فريقك إلى endpoint من نوع HTTPS تملكه. استخدمها لتغذية أداة المناوبة، أو طابور التذاكر، أو لوحة العمليات الخاصة بك. webhooks التنبيهات منفصلة عن webhooks التحقق. ترسل webhooks التحقق نتائج الجلسات والكيانات والمعاملات إلى تطبيقك. أما webhooks التنبيهات فتُخبر فريقك بأن شيئاً يحتاج إلى اهتمام: تحقق ينتظر المراجعة، أو دفعة فاشلة، أو حادثة في خدمة. ولكل منها payload خاص، وسر توقيع خاص، وتوقيع خاص، وجدول إعادة محاولة خاص.

إعداد الوجهة

تُهيَّأ webhooks التنبيهات في Business Console، وليس من خلال API. يمكن للأعضاء الذين يملكون صلاحية إدارة إعدادات المؤسسة إضافة الوجهات وتعديلها واختبارها.
1

أضف الوجهة

في إعدادات المؤسسة > إشعارات الفريق، أضف وجهة webhook التنبيهات مع عنوان URL لـ endpoint الخاص بك. يجب أن يستخدم عنوان URL الصيغة https:// وأن يُحلّ إلى عنوان عام.
2

احفظ سر التوقيع

يعرض Didit سر التوقيع الكامل، الذي يبدأ بـ whsec_، مرة واحدة فقط. احفظه الآن: بعد ذلك تعرض Business Console آخر أربعة أحرف منه فقط.
3

وجّه التنبيهات إليها

إضافة الوجهة لا ترسل إليها أي شيء بعد. أضف الوجهة إلى قواعد التوجيه الخاصة بالتنبيهات التي تريد أن تستقبلها.
4

أرسل اختبارًا

انقر إرسال اختبار لإرسال تنبيه alert.test، وتحقق من أن endpoint الخاص بك يقبله.
يمكن أن تحتوي المؤسسة على ما يصل إلى 25 وجهة في إشعارات الفريق. لا يصل إلى الوجهة إلا النشاط في بيئة الإنتاج. لا تُرسَل إليها أبداً التنبيهات المتعلقة بعمليات التحقق في البيئة التجريبية، أو بالتحقق من الشركات (KYB)، أو بالمعاملات، أو بتطابقات AML.

أنواع التنبيهات

payload

كل تنبيه هو طلب POST بجسم JSON. يرسل Didit الجسم بصيغة JSON مضغوطة، مع ترتيب مفاتيحه أبجدياً. هذا المثال منسّق للقراءة:
يحتوي data دائماً على:
  • event: مفتاح الحدث، مثلاً session_in_review.
  • label وvalue: موضوع التنبيه، مثلاً Session و#1042.
تضيف بعض أنواع التنبيهات مفاتيح إلى data:
  • alert.billing.autorefill_failed يضيف paused، وهو قيمة منطقية تكون true عندما يكون الشحن التلقائي متوقفاً الآن إلى أن تحدّث البطاقة.
  • alert.service.degraded وalert.service.recovered يضيفان service وstatus وincident_id وservice_name وstate وaffected وcountry_name وstarted_at وresolved_at وduration_minutes وtitle وbody. قيمة status هي degraded أو down في alert.service.degraded، وهي recovered في alert.service.recovered. يستخدم service مفاتيح الخدمات في GET /v3/status/، ويطابق incident_id قيمة id لحادثة هناك.
لا تتضمن التنبيهات أبداً بيانات شخصية للمستخدم النهائي أو بيانات المستندات. وهي تحدد الجلسة أو المعاملة أو أي عنصر آخر برقمه، وترتبط به في وحدة التحكم. تجاهل قيم webhook_type ومفاتيح data التي لا تعرفها، حتى لا يتعطل endpoint الخاص بك بالعناصر الجديدة.

رؤوس الطلب

التحقق من التوقيع

X-Signature-V2 هو قيمة HMAC-SHA256 المُرمَّزة بالست عشري للسلسلة <X-Timestamp>.<raw body>، ويُوقَّع باستخدام سر التوقيع الخاص بوجهة webhook لديك.
  • استخدم السر الكامل كما عرضه Didit تماماً، بما في ذلك البادئة whsec_.
  • وقّع بايتات الطلب الخام كما استلمتها. قد يؤدي تحليل JSON ثم إعادة تسلسله إلى تغيير البايتات وفشل التحقق.
  • قارن التوقيعات بزمن ثابت.
  • ارفض أي طلب يتجاوز الفرق بين X-Timestamp وساعتك 5 دقائق. يوقّع Didit كل محاولة، بما فيها كل إعادة محاولة، بطابع زمني جديد، لذلك لا ترفض هذه النافذة أي إعادة محاولة صحيحة أبداً.
  • استجب لفشل التحقق بالرمز 400. الاستجابة 401 أو 403 أو 404 أو 410 تُعلّم الوجهة لإعادة الربط (انظر إعادة المحاولات).
لا تُوقَّع webhook الخاصة بالتنبيهات بالطريقة نفسها التي تُوقَّع بها webhook الخاصة بالتحقق. الرأس يحمل الاسم نفسه X-Signature-V2، لكن السلسلة الموقّعة مختلفة، ولا ترسل webhook الخاصة بالتنبيهات أي X-Signature أو X-Signature-Simple. لا تعِد استخدام أداة التحقق من webhook الخاصة بالتحقق لديك.

Node.js (Express)

Python (Flask)

تدوير سر التوقيع

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

إعادة المحاولات

يعامل Didit أي استجابة 2xx على أنها مُسلَّمة. تنتظر كل محاولة حتى 5 ثوانٍ لاستجابتك، ولا تتبع عمليات إعادة التوجيه. يعيد Didit محاولة التنبيه بعد انتهاء المهلة، أو فشل الاتصال، أو استجابة 5xx، أو استجابة 408 أو 425 أو 429. يعيد المحاولة حتى 5 مرات، على مدى نحو 24 ساعة: كل استجابة أخرى نهائية، بما في ذلك 3xx وأي 4xx أخرى. الاختبار المُرسل بزر إرسال اختبار يحصل على محاولة واحدة فقط ولا تتم إعادة محاولته أبداً. الاستجابات 401 و403 و404 و410 تُعلّم الوجهة أيضاً لإعادة الربط، فتعرضها لوحة التحكم بحالة إعادة الربط. وكذلك الأمر إذا كان عنوان URL يُحلّ إلى عنوان خاص أو محظور بطريقة أخرى عندما يرسل Didit. يواصل Didit إرسال التنبيهات الجديدة إلى الوجهة، وتعود إلى النشاط بعد التسليم الناجح التالي أو عند تحديث عنوان URL الخاص بها. يعرض الإشعارات الأخيرة في إشعارات الفريق كل عملية تسليم مع نتيجتها، ويمكنك إعادة محاولة عملية تسليم فاشلة من هناك.

ذات صلة

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