الـ Webhook الموقّع: ليه تكاملك لازم يتحقّق منه

الـ Webhook هو إن المنصة تبعت لسيرفرك طلب HTTP كل ما يحصل حدث. التوقيع هو الحاجة اللي بتثبت إن الطلب فعلًا منها. من غير التحقق من التوقيع، الرابط بتاعك مفتوح لأي حد: يقدر يبعت «الدفع تم» وسيرفرك يصدّقه.

التحقق لازم يبقى على البايتس الخام

التوقيع محسوب على نص الطلب زي ما اتبعت بالظبط. لو أي middleware حوّل الـ JSON لكائن ورجّع تسلسله، الناتج مش هيطابق التوقيع — والرد المعتاد على ده، للأسف، هو إن حد يقفل التحقق. لازم تمسك البايتس الخام قبل أي حاجة تلمسها.

رُد ٢٠٠ الأول، واشتغل بعدين

رجّع ٢٠٠ بمجرد ما (أ) تتحقق من التوقيع و(ب) تكتب الحمولة الخام في مكان دائم. الشغل الحقيقي بيتعمل بعد كده من طابور. السبب إن المنصات بتعيد الإرسال على أي رد مش ٢٠٠، وبتسيب المحاولة بعد مدة — فمعالج بطيء بسبب خدمة تانية بطيئة بيحوّل عطل مؤقت لفقدان رسايل دائم. وكمان الإشعار الواحد ممكن يشيل لحد ١٠٠٠ تحديث، وده مش بيتعالج جوّه مهلة رد.

وده سؤال Meta نفسها مش واضحة فيه

قد إيه المنصة بتفضل تحاول قبل ما تسيب الإشعار؟ صفحة Webhooks على Graph API بتقول ٣٦ ساعة، وصفحة Cloud API بتقول لحد ٧ أيام. **الاتنين من Meta، والاتنين مختلفين.** إحنا مش هنختار رقم ونكتبه كإنه الحقيقة. التصميم الصح إنك ماتعتمدش على الرقم أصلًا: اكتب الحمولة بدري، وخلّي المعالجة لا تعتمد على الترتيب، وخليك idempotent — ساعتها الرقم مايفرقش.

التكرار متوقّع، مش استثناء

• افترض إن كل حدث ممكن يوصلك أكتر من مرة، وإن الترتيب مش مضمون.
• مفتاح التكرار يتاخد من معرّف المنصة نفسها — مش من هاش للحمولة، لأن حمولة نفس الحدث ممكن تختلف بين الأصل والإعادة.
• المفتاح ده يبقى عمود بقيد فريد في قاعدة البيانات، مش كاش في الذاكرة.
• المهلة (timeout) شكلها زي الفشل بالظبط من ناحية المُرسِل — فالمعالجة البطيئة هي نفسها بتصنع التكرار.

السؤال اللي تسأله لأي حد بيبني لك تكامل: «بتتحقق من التوقيع على البايتس الخام؟» ولو الإجابة «إيه ده؟»، ده الجواب.