التعريف
Webhook هو آلية برمجية تُتيح لنظامٍ ما أن يُرسل بيانات تلقائيًا إلى رابط URL مُحدَّد (Endpoint) فور وقوع حدث مُعيَّن، دون أن يطلب الطرف الآخر هذه البيانات بنفسه. بعبارة أبسط: بدلًا من أن يسأل نظامك المتجرَ الإلكتروني كل دقيقة «هل وصل طلب جديد؟»، يقوم المتجر بدفعه إليك أنت مباشرةً لحظة إنشاء الطلب.
في سياق التجارة الإلكترونية المباشرة (DTC)، يُعدّ الـ Webhook العمود الفقري لمزامنة الأحداث اللحظية بين منصّة المتجر (Shopify، Salla، Zid، WooCommerce) وبقيّة أنظمة التشغيل: إدارة المخزون (ERP)، أنظمة إدارة الطلبات (OMS)، شركات الشحن، بوابات الدفع، وأدوات التسويق الآلي.
تشبيه عملي
تخيّل أنك تدير مطعمًا. الطريقة التقليدية (Polling) تشبه أن يُرسل النادل شخصًا إلى المطبخ كل 30 ثانية ليسأل: «هل جاهز أي طبق؟». أمّا الـ Webhook فهو أن يضغط الطاهي زرًّا لحظة اكتمال الطبق، فيصل النادل فورًا. النتيجة: وقت أقل، جهد أقل، وطبق ساخن.
المعادلة التقنية
يُختصر الفرق بين الـ Webhook والـ Polling في العلاقة التالية:
طلبات الـ Polling في الساعة = (60 ÷ فترة الاستقصاء بالدقائق) × عدد الأنظمة طلبات الـ Webhook في الساعة = عدد الأحداث الفعلية فقط
مثال رقمي: متجر DTC يستقبل 1,200 طلب يوميًا، ويربط 4 أنظمة (OMS + ERP + شركة شحن + CRM). مع Polling كل دقيقة:
(60 × 24) × 4 = 5,760 طلبًا يوميًا لمزامنة 1,200 حدث فقط نسبة الهدر = (5,760 − 1,200) ÷ 5,760 ≈ 79%
مع Webhook تنخفض الطلبات إلى 1,200 فقط، أي توفير يقارب 4,560 طلبًا يوميًا وتقليل زمن التأخير من متوسط 30 ثانية إلى أقل من 500 ملّي ثانية.
جدول المقارنة: Webhook مقابل Polling
| المعيار | Webhook | Polling (الاستقصاء الدوري) |
|---|---|---|
| آلية العمل | النظام المُرسِل يدفع البيانات عند الحدث | نظامك يسأل بشكل متكرّر |
| زمن التأخير (Latency) | 100–500 ملّي ثانية | يعتمد على الفترة (30 ثانية – 5 دقائق) |
| استهلاك الطلبات (API Calls) | منخفض جدًا (فقط عند الحدث) | مرتفع ومتكرّر دائمًا |
| التكلفة على البنية التحتية | أقل بنسبة 60–80% | أعلى بسبب الطلبات الفارغة |
| التعقيد في الإعداد | متوسط (يتطلّب Endpoint آمن) | بسيط نسبيًا |
| المناسبة | الطلبات، الشحن، الدفع، المخزون | التقارير الدورية، المزامنة الجماعية |
| المخاطر | فقدان الحدث إذا كان الـ Endpoint معطّلًا | تأخير في البيانات الحرجة |
حالات الاستخدام في DTC
1. إنشاء طلب جديد (order/create): يُرسل المتجر تفاصيل الطلب إلى نظام إدارة الطلبات فورًا، فيبدأ التجهيز خلال ثوانٍ.
2. تحديث حالة الشحن (fulfillment/update): تُرسل شركة الشحن رقم التتبّع إلى المتجر، فيُرسل المتجر بدوره إشعارًا للعميل عبر واتساب أو البريد.
3. تأكيد الدفع (payment/success): تُخطر بوابة الدفع نظامك لتحديث حالة الطلب إلى «مدفوع» وإطلاق فاتورة ضريبية تلقائية.
4. تحديث المخزون (inventory/update): عند بيع آخر قطعة، يُرسل Webhook إلى المتجر لإخفاء المنتج من الواجهة فورًا ومنع البيع الزائد.
5. استرجاع أو إلغاء (refund/create): يُحدَّث نظام الولاء ونظام المحاسبة تلقائيًا.
الأخطاء الشائعة
- إهمال التحقق من التوقيع (Signature Verification): كل Webhook يجب أن يحمل ترويسة توقيع مثل X-Shopify-Hmac-SHA256. بدون التحقق، أي جهة خارجية قد ترسل بيانات مزيّفة.
- عدم إرجاع رمز 200 خلال 5 ثوانٍ: معظم المنصّات تُعيد المحاولة حتى 19 مرة خلال 48 ساعة، ثم تُوقف الإرسال. الحل: استقبل الطلب، خزّنه في Queue، ثم عالجه لاحقًا.
- غياب معالجة التكرار (Idempotency): قد يصل الحدث نفسه مرتين. استخدم event_id لمنع تنفيذ العملية مرّتين (مثل خصم المخزون مرتين).
- الاعتماد الكامل على Webhook دون خطة نسخ احتياطي: إذا تعطّل الـ Endpoint، تفقد الأحداث. اجعل Polling احتياطيًا كل ساعة للمراجعة.
- استخدام HTTP بدل HTTPS: يكشف بيانات العملاء، وهو مخالف لمعايير PCI-DSS وGDPR.
- إهمال تسجيل الأحداث (Logging): بدون سجل، يصعب تشخيص سبب عدم تحديث طلب معيّن.
أرقام مرجعية
- 99.9% من منصّات DTC الكبرى (Shopify، Salla، Zid) تعتمد Webhook كمصدر أساسي للأحداث.
- 5 ثوانٍ هي المهلة القصوى للرد قبل اعتبار الطلب فاشلًا.
- 19 محاولة هي الحد الأقصى لإعادة الإرسال في Shopify خلال 48 ساعة.
مصطلحات ذات صلة
- API Endpoint: العنوان الذي يستقبل بيانات الـ Webhook.
- Payload: حمولة البيانات المُرسَلة بصيغة JSON عادةً.
- HMAC Signature: التوقيع الأمني للتحقق من مصدر الطلب.
- Idempotency Key: مفتاح لمنع التنفيذ المزدوج.
- Event-Driven Architecture: نمط معماري يبني النظام حول الأحداث.
- Queue / Message Broker: وسيط لتخزين الأحداث ومعالجتها بأمان (مثل RabbitMQ أو SQS).
- Retry Policy: سياسة إعادة المحاولة عند الفشل.
