التحقق من تسليم Webhooks
تحقق من نقطة النهاية التي يجب أن تستقبل الحدث
افتح Settings → Integrations → Webhooks. تأكد من تفعيل نقطة النهاية واشتراكها في الحدث المطلوب. صلاحية Webhooks للحساب تشمل نقاط النهاية والأسرار وسجلات التسليم للحساب كله؛ صلاحية CRM وحدها لا تمنح هذا الوصول.
للرسائل القصيرة، راجع اختيار معرّفات المرسِل. All Sender IDs يشمل جميع أحداث SMS المشترك بها للحساب؛ أما القائمة المحددة فتُطابق مع مرسِل الرسالة الأصلي. لا تتأثر أنواع الأحداث الأخرى.
تغيير الفلتر لا يعيد إرسال الأحداث السابقة
يُفحص اختيار المرسِل في كل محاولة تسليم، بما فيها المحاولات المتكررة. تغييره لا يعيد الأحداث القديمة ولا يغيّر وجهة عمليات التسليم الموجودة في قائمة الانتظار.
اقرأ محاولة التسليم
يعرض سجل التسليم الوقت والحالة والحدث ونقطة النهاية واستجابة HTTP والخطأ. حدّد الحدث ونقطة النهاية للمحاولة التي تفحصها، ثم قارنها بسجلات التطبيق المستقبِل.
لا توجد محاولة مطابقة
راجع اشتراكات الأحداث وحالة نقطة النهاية وفلاتر مرسِل SMS قبل فحص كود التطبيق المستقبِل.
محاولة فاشلة
استخدم استجابة HTTP أو خطأ الشبكة لتحديد طبقة الاستقبال التي رفضت الطلب أو لم تستقبله.
إقرار استلام ناجح
افحص معالجة التطبيق بشكل مستقل. إقرار HTTP لا يثبت اكتمال جميع الإجراءات اللاحقة.
إذا كان جدار الحماية يقيّد الطلبات الواردة، استخدم قائمة عناوين IP الحالية للتسليم في إعدادات الحساب. تحقّق من التوقيعات حتى مع استخدام قائمة IP مسموح بها.
راجع التحقق من التوقيع أولاً
يرسل IllyVoIP طلبات POST بصيغة JSON مع الترويسة Illyvoip-Signature. تحقّق منها باستخدام سر Webhook وجسم الطلب الأصلي الخام قبل معالجة الحدث.
تتكون البيانات الموقّعة من الطابع الزمني ونقطة وجسم الطلب الخام. تحليل JSON وإعادة ترميزه قبل التحقق قد يغيّر هذه البيانات. راجع الوثائق الحالية لطريقة HMAC SHA-256 الدقيقة.
سر توقيع Webhook منفصل عن مفتاح API الخاص بالعميل. إذا تم تدويره، حدّث التطبيق المستقبِل وفق آلية تغيير بيانات الاعتماد المعتادة. لا تكشف أيّاً منهما في سجلات الدعم.
افهم استجابة HTTP
أي رمز 2xx
يؤكد التسليم. تكفي استجابة 200 فارغة.
فشل شبكة أو غياب الاستجابة أو 408 أو 429 أو 5xx
مؤهل لإعادة المحاولة وفق السياسة الموثّقة.
3xx أو رموز 4xx الأخرى
يوقف التسليم. افحص إعادة التوجيه وقواعد الوصول والتحقق لدى المستقبِل بدلاً من انتظار إعادة محاولة تلقائية.
أكّد استلام الأحداث الصحيحة سريعاً وضع العمل البطيء في قائمة منفصلة. اجعل التطبيق المستقبِل يتعامل بأمان مع وصول الحدث نفسه أكثر من مرة.
استخدم معرّف الحدث لمنع تكرار العمل
احفظ الحقل id من الجسم كمفتاح ثابت لمنع التكرار. الترويسة Illyvoip-Delivery تحدد مهمة التسليم، ولا تحل محل معرّف الحدث.
لربط رسائل SMS بالأحداث، اتبع وثائق استجابة الإرسال وWebhooks الحالية. معرّفات مهام التسليم ومعرّفات الرسائل لها وظائف مختلفة.
إذا احتجت مساعدة، قدّم معرّف الحدث ووقت المحاولة ومنطقته الزمنية ورمز الاستجابة وخطأ المستقبِل بعد إزالة البيانات الحساسة. حافظ على سرية أسرار التوقيع ومفاتيح API ومحتوى الأحداث غير ذات الصلة.
إنشاء نقطة نهاية وتعديلها وإيقاف استخدامها
في Integrations → Webhooks، اختر Add webhook وأدخل عنوان HTTPS المستقبِل وحدد الأحداث اللازمة فقط. راجع فلاتر مرسِل SMS إن وجدت ثم احفظ. خزّن سر التوقيع بأمان عند عرضه؛ فهو ليس مفتاح API للحساب.
استخدم Edit على نقطة النهاية الصحيحة لتغيير الاسم والاشتراكات والفلاتر أو التفعيل. العنوان للقراءة فقط: أنشئ نقطة نهاية جديدة لعنوان مختلف وحدّث سرها في التطبيق المستقبِل ثم أوقف القديمة عندما تصبح جاهزاً. تحقق من الصف المحفوظ قبل الاختبار. نقاط النهاية المكررة قد ترسل إشعارات منفصلة للمستقبِل نفسه. لا تحذف نقطة قديمة قبل معرفة التطبيق الذي يستخدمها؛ حذفها لا يلغي الأحداث التي عولجت بالفعل.
نسّق تغييرات سر التوقيع
دوّر السر فقط عندما تكون مستعداً لتحديث التطبيق المستقبِل. اقرأ التأكيد واحفظ السر الجديد بأمان وحدّث المستقبِل قبل الاعتماد على التسليم التالي. لا تفترض أن السر القديم سيعمل إلى الأبد أو أن التدوير يعيد الأحداث السابقة. سجل التسليم نافذة للتشخيص الحديث وليس أرشيفاً كاملاً؛ احتفظ بسجلات آمنة خاصة بك للأحداث ومعالجتها.