تسجل منصة تتبع الروابط ما حدث لروابطك. أما webhook فهو إخبار المنصة لأنظمتك الأخرى بما يحدث لحظة حدوثه، بدلًا من انتظار أن يفتح أحدهم لوحة التحكم. وبالجمع بينهما يظهر رابط حملة جديد في نظام CRM لحظة إنشائه، أو يؤدي فتح رابط سري إلى تحديث تذكرة دعم.
واختيار منصة تتبع روابط مع تكاملات webhook يعني أن تنظر أبعد من عبارة «تدعم webhooks»: أي الأحداث ترسل، وكيف تؤمّنها، وما الذي لا ترسله. يشرح هذا الدليل كل ذلك، وكيف تبني مستقبِلًا يُعتمد عليه، ومتى تكون واجهة API الأداة الأفضل.
فيمَ تفيد webhooks التي ترسلها منصة الروابط
ثلاث مهام تتكرر.
- إبقاء الأنظمة متزامنة. الرابط الذي يُنشأ في المنصة يظهر في سجل الحملة داخل نظام CRM أو أداة إدارة المشاريع، مع نهاية الرابط ووجهته، دون أن ينسخه أحد.
- تشغيل سير العمل. الرابط السري الذي فُتح يعني أن التسليم اكتمل، والرابط الذي حُذف نهائيًا دون أن يؤكد المستلم استلامه يفتح بلاغ حادث.
- تغذية مستودع البيانات. تصل الأحداث إلى طابور ثم إلى جدول، وهناك تنضم إلى بقية بياناتك.
لكن webhooks لا تصلح للعد. فلوحة التحكم التي تزيد رقمًا مع كل webhook ستختلف أرقامها عن تقرير المنصة نفسها في أول مرة يُعاد فيها إرسال حدث أو يتأخر. استخدم واجهة API أو التصدير للأرقام، و webhooks للإجراءات.
أي الأحداث تبحث عنها
تختلف المنصات فيما ترسله من أحداث. فاطلب القائمة، لا مجرد اسم الميزة.
| فئة الأحداث | أحداث معتادة | تفيد في |
|---|---|---|
| دورة حياة الرابط | الإنشاء، التحديث، الحذف | المزامنة مع CRM، وسجل التدقيق، واكتشاف التعديلات غير المقصودة |
| دورة حياة السر | الإنشاء، الفتح، الحذف النهائي | تأكيد التسليم، وتشغيل بلاغات الحوادث |
| أحداث النقر | لكل نقرة أو على دفعات | الأتمتة الفورية، مع الأحجام الكبيرة |
| أحداث النطاق | التحقق، إصدار الشهادة | تنبيهات فريق التشغيل |
تغطي webhooks في LinkPilot دورة حياة الرابط (link.created و link.updated و link.deleted) ودورة حياة السر (secret.created و secret.viewed و secret.burned). أما بيانات النقرات فمتاحة عبر واجهة API للإحصاءات وتصدير CSV، لا عبر webhook لكل نقرة، وهذا هو التقسيم المناسب لمعظم الفرق: النقرات بيانات تقارير كبيرة الحجم، في حين أن أحداث دورة الحياة هي التي يجب أن تُطلق إجراءً.
وإن كان سير عملك يحتاج فعلًا إلى رد فعل على كل نقرة، فتأكد من أن المنصة ترسلها على دفعات أو تحدّ من معدلها، وإلا بنيت مستقبِلًا ينهار في أول مرة ينتشر فيها منشور على نطاق واسع.
ما الذي تقيّمه أيضًا
- التوقيع. يجب أن تحمل كل عملية إرسال توقيعًا محسوبًا بسر تحتفظ به أنت، حتى ترفض نقطة الاستقبال لديك أي طلب مزور. والمنصة التي ترسل webhooks بلا توقيع تطلب منك أن تثق بأي طلب POST.
- إعادة المحاولة والترتيب. اعرف كم مرة يُعاد إرسال الحدث الفاشل وعلى مدى أي فترة، وافترض أن الأحداث قد تصل بغير ترتيبها.
- معرّفات الأحداث. المعرّف الفريد لكل حدث هو ما يجعل معالجة الحدث مرة واحدة فقط ممكنة.
- إدارة نقاط الاستقبال. عدة نقاط استقبال في كل مساحة عمل، واشتراك في كل حدث على حدة، وسجل إرسال تقرؤه حين يحدث خطأ.
- واجهة API إلى جانبها. webhooks للتشغيل، وواجهة API لكل ما عدا ذلك. تأكد من أن إنشاء الروابط والإحصاءات والتصدير متاحة كلها برمجيًا، وأن صلاحيات المفاتيح يمكن تقييدها. تستخدم واجهة API في LinkPilot مفاتيح bearer تبدأ بالبادئة
lp_live_، وهي متاحة في كل الخطط. - صلاحيات الفريق. تحديد من يستطيع إضافة نقطة استقبال webhook مسألة مهمة، لأن نقطة الاستقبال تتلقى بيانات. ويجب أن تتيح الأدوار للمشرف إدارة نقاط الاستقبال وأن تمنع الآخرين منها.
ابنِ مستقبِلًا لا ينهار
- تحقق من التوقيع أولًا. احسب التوقيع المتوقع من النص الخام للطلب ومن سرك، وقارن بينهما في زمن ثابت، وارفض كل ما يفشل قبل تحليله.
- أرسل الإقرار بسرعة. أعد استجابة 2xx خلال ثانية أو ثانيتين. ونفّذ العمل الفعلي من طابور، حتى لا يتسبب بطء نظام CRM في إعادة المحاولات.
- خزّن معرّفات الأحداث وتجاهل كل ما رأيته من قبل. إعادة المحاولة أمر عادي، والمعالجة المزدوجة خطأ في نظامك أنت.
- حدد الحقول صراحةً. انقل نهاية الرابط والوجهة والوسوم والطوابع الزمنية التي تحتاجها إلى مخططك الخاص. ولا تخزن الحمولة كاملة على أنها المرجع، فهي إشعار لا سجل.
- سجّل كل عملية إرسال مع معرّفها ونتيجتها، فإذا قال سجل المنصة إن الحدث وصل وقال نظامك إن شيئًا لم يحدث، عرفت أين ذهب.
- أطلق تنبيهًا عند الصمت. إذا كانت نقطة استقبال تتلقى أحداثًا كل ساعة عادةً ثم صمتت يومًا كاملًا، فقد تعطل شيء في أحد الطرفين.
اختبر بنقطة استقبال تجريبية وبإرسال الاختبار الذي توفره المنصة قبل أول حملة حقيقية. أنشئ رابطًا، ثم عدّله، ثم احذفه، وراقب وصول الأحداث الثلاثة.
احمِ البيانات
حمولات webhook تصف الروابط والأسرار، لا الأشخاص. فأبقِها كذلك.
- لا تضع بيانات شخصية أبدًا في نهايات الروابط أو الوسوم، لأنها ستنتقل في كل حمولة تخص ذلك الرابط.
- قيّد نقطة الاستقبال بحيث لا تقبل إلا الطلبات الواردة من المنصة، بالتوقيع، وبعنوان المصدر حيث أمكن.
- خزّن سر التوقيع في مدير أسرار، لا في ملف إعدادات المستقبِل، وغيّره وفق جدول زمني. وإذا اضطررت إلى تسليم السر إلى متعاقد يبني المستقبِل، فأرسله عبر رابط سري لمرة واحدة. ويشرح دليل سر توقيع webhook هذا التسليم.
- ضع الموافقة في حسبانك حين تنتقل بيانات النقرات إلى نظام CRM. فسجل النقرة المربوط بعميل يُعد بيانات شخصية في معظم قواعد الخصوصية.
قِس التكامل نفسه
- نسبة نجاح الإرسال من سجل المنصة.
- تأخر المعالجة من الطابع الزمني للحدث إلى السجل في نظامك.
- نسبة التكرار، ويجب أن تكون منخفضة لكنها لا تصل إلى الصفر أبدًا.
- المطابقة: مرة في الأسبوع، قارن عدد الروابط وإجمالي النقرات من واجهة API بما تحتفظ به أنظمتك. والفرق يعني إرسالًا ضائعًا أو خطأ في المستقبِل.
منصة تتبع الروابط التي تدعم webhooks تجعل روابطك جزءًا من بقية أدواتك. فاختر منصة توقّع ما ترسله، وتخبرك بالأحداث الموجودة بالضبط، وتمنحك واجهة API للأرقام. ثم ابنِ المستقبِل على أساس أن إعادة المحاولة هي الحالة العادية، لأنها كذلك فعلًا.