الـ Webhook هو إشعار آلي يرسله نظام إلى نظام آخر لحظة وقوع حدث محدد، ويُسلَّم في صورة طلب HTTP إلى عنوان URL مُعدّ مسبقًا، بدلًا من أن يضطر النظام المستقبِل إلى السؤال المتكرر عمّا إذا كان أي شيء قد تغيّر. وفي إدارة خلاصة المنتجات، تتيح الـ Webhooks لتغيير السعر في نظام ERP، أو لطلب جديد في المتجر الإلكتروني، أو لتحديث مستوى المخزون في نظام المستودع أن تُخطِر منصة إدارة الخلاصة فورًا، بدلًا من أن تضطر هذه المنصة إلى فحص التغييرات (polling) وفق مؤقت زمني. وهي تحوّل تحديثات الخلاصة من مهمة دفعية مجدولة إلى تحديثات قائمة على الأحداث.
لماذا تهمّ في إدارة خلاصة المنتجات
إن الـ polling، أي الفحص المتكرر لنظام المصدر بحثًا عن تغييرات، يهدر الموارد ويتسبب في تأخير: فإذا كانت أداة الخلاصة تفحص المخزون كل خمس عشرة دقيقة، فقد يبقى نفاد المخزون ظاهرًا في قناة التسوق لمدة تصل إلى خمس عشرة دقيقة قبل اكتشافه. أما الـ Webhook فيزيل هذا التأخير لأن نظام المصدر يدفع التغيير فورًا، بحيث يمكن سحب منتج سُجّل كنافد من المخزون عند 2:00:03 م من القوائم النشطة عند 2:00:04 م. وتبرز أهمية هذه الفورية خصوصًا في كل ما يرتبط بالوقت: العروض الخاطفة، وإطلاقات المخزون المحدود، ومطابقة الأسعار مع المنافسين، حيث قد يعني حتى التأخير القصير بيع منتج لم يعد متاحًا أو الإعلان عن سعر لم يعد دقيقًا. ولأن الـ Webhooks تعتمد على آليات الطلب والاستجابة نفسها التي يعتمد عليها أي استدعاء API آخر، فإنها تندمج في مسارات أتمتة الخلاصة القائمة دون الحاجة إلى نمط تكامل منفصل.
آلية العمل
يتطلب إعداد الـ Webhook تسجيل عنوان URL للاستدعاء (callback) لدى نظام المصدر، مثل أداة إدارة المستودعات أو نظام إدارة المحتوى أو معالج الدفع، وتحديد الأحداث التي ينبغي أن تطلق إشعارًا. وعند وقوع الحدث، يرسل نظام المصدر طلب HTTP POST إلى العنوان المسجَّل، مع تفاصيل الحدث في متن الطلب، وبيانات وصفية مثل نوع الحدث أو توقيع للتحقق ضمن HTTP headers. ثم يعالج النظام المستقبِل، وهو عادةً منصة الخلاصة، هذه الحمولة ويحدّث بيانات المنتج ذات الصلة. ولأن الـ Webhooks تُطلَق في الوقت الفعلي وغالبًا على شكل دفعات متتالية (تخيّلوا تحديثًا جماعيًا للأسعار يطلق مئات الأحداث الفردية دفعة واحدة)، فإن معظم الأنظمة تضع استدعاءات الـ Webhook الواردة في طابور وتعالجها بشكل غير متزامن بدلًا من معالجة كل منها فورًا وبشكل متزامن، مما يمنع إرهاق الطرف المستقبِل. وتُعدّ الـ Webhooks لبنة أساسية في أتمتة سير العمل الأوسع، لأنها تتيح لإجراء واحد في نظام غير مرتبط أن يطلق سلسلة من تحديثات الخلاصة اللاحقة دون أن يراقب أحد التغيير يدويًا.
مثال
<item>
<g:id>SKU-55810</g:id>
<title>Wireless Charging Pad - Matte Black</title>
<g:availability>out of stock</g:availability>
<custom_label_1>updated_via_webhook</custom_label_1>
<last_event>inventory.zero</last_event>
<last_updated>2026-08-15T14:00:04Z</last_updated>
</item>هنا يعكس الحقل last_event حمولة الـ Webhook الصادرة عن نظام المخزون والتي أطلقت تغيير حالة توفر هذا المنتج، ويمثل الطابع الزمني last_updated شبه الفوري النتيجة العملية للتحديثات القائمة على الأحداث بدلًا من التحديث الدفعي المجدول.
مفاهيم ذات صلة
تعتمد الـ Webhooks على بنية الطلب نفسها التي يعتمد عليها أي استدعاء API، لكن بصورة معكوسة، إذ يبادر نظام المصدر بالإرسال بدلًا من منصة الخلاصة؛ وتحمل HTTP headers في ذلك الطلب بيانات المصادقة والبيانات الوصفية للحدث اللازمة للوثوق به وتوجيهه بشكل صحيح. وعند ربطها معًا عبر الأنظمة، تصبح الـ Webhooks طبقة المحفِّز وراء معظم أتمتة سير العمل في إدارة الخلاصة، وهي السبب في أن تغيّرًا واحدًا في المخزون قد يتتابع فيؤدي إلى تحديث قائمة المنتج، وإيقاف إعلان مؤقتًا، وتحديث مدخل في الخلاصة دون أن يتدخل أي شخص يدويًا.
