إعداد الوجهة
تُهيَّأ webhooks التنبيهات في Business Console، وليس من خلال API. يمكن للأعضاء الذين يملكون صلاحية إدارة إعدادات المؤسسة إضافة الوجهات وتعديلها واختبارها.1
أضف الوجهة
في إعدادات المؤسسة > إشعارات الفريق، أضف وجهة webhook التنبيهات مع عنوان URL لـ endpoint الخاص بك.
يجب أن يستخدم عنوان URL الصيغة
https:// وأن يُحلّ إلى عنوان عام.2
احفظ سر التوقيع
يعرض Didit سر التوقيع الكامل، الذي يبدأ بـ
whsec_، مرة واحدة فقط.
احفظه الآن: بعد ذلك تعرض Business Console آخر أربعة أحرف منه فقط.3
وجّه التنبيهات إليها
إضافة الوجهة لا ترسل إليها أي شيء بعد.
أضف الوجهة إلى قواعد التوجيه الخاصة بالتنبيهات التي تريد أن تستقبلها.
4
أرسل اختبارًا
انقر إرسال اختبار لإرسال تنبيه
alert.test، وتحقق من أن endpoint الخاص بك يقبله.أنواع التنبيهات
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تُعلّم الوجهة لإعادة الربط (انظر إعادة المحاولات).
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 الخاص بها.
يعرض الإشعارات الأخيرة في إشعارات الفريق كل عملية تسليم مع نتيجتها، ويمكنك إعادة محاولة عملية تسليم فاشلة من هناك.
ذات صلة
- webhook الخاصة بالتحقق: نتائج الجلسات والكيانات والمعاملات لتطبيقك.
- حالة الخدمة: الخلاصة العامة التي تغذي
alert.service.degradedوalert.service.recovered. - المراجعة اليدوية: ما يجب فعله مع عملية تحقق قيد المراجعة.