Webhooks وHookURL في Whats360: الدليل العملي لربط WhatsApp بالمتاجر والـCRM والأنظمة البرمجية

إذا كان لديك متجر إلكتروني أو CRM أو تطبيق SaaS أو نظام داخلي، فالمشكلة ليست فقط في قدرة النظام على تنفيذ عملية معينة، وإنما في الطريقة التي يعرف بها نظام آخر أن هذه العملية حدثت في اللحظة المناسبة.

تم إنشاء طلب جديد؟ تم الدفع؟ وصلت رسالة WhatsApp؟ تغيرت حالة الشحنة؟ سجل عميل جديد؟

في الأنظمة التقليدية يمكن الاعتماد على الاستعلام الدوري Polling لمعرفة ما إذا كان هناك حدث جديد. لكن عندما يكون المطلوب تنفيذ إجراء بمجرد وقوع الحدث، تصبح Webhooks من أهم آليات الربط بين الأنظمة الحديثة.

في هذا السياق، توفر Whats360 طبقة ربط يمكن استخدامها لنقل الأحداث والبيانات بين WhatsApp والأنظمة الخارجية، بحيث يمكن تحويل رسالة أو طلب أو تحديث إلى إجراء آلي داخل متجر أو CRM أو تطبيق أو Workflow.

ما المشكلة التي يحلها Webhook فعليًا؟

لفهم قيمة Webhook، تخيل متجرًا إلكترونيًا يريد إرسال رسالة WhatsApp للعميل مباشرة بعد إنشاء طلب جديد.

هناك طريقة تقليدية تعتمد على Polling، حيث يقوم النظام بالسؤال بشكل دوري عن وجود بيانات جديدة:

هذا النموذج يعني أن النظام يبحث عن الحدث بدل أن يتم إخباره به.

أما في نموذج Event-driven Architecture، فعندما يقع الحدث يتم إرسال Notification إلى النظام الذي يحتاج إلى معرفته:

الفكرة الأساسية إذن ليست مجرد إرسال رسالة، وإنما جعل الحدث نفسه نقطة انطلاق لعملية آلية.

ويمكن تطبيق النموذج نفسه على الطلبات، المدفوعات، الرسائل، تحديثات الشحن، العملاء الجدد، Leads، بيانات CRM وغيرها من الأحداث التي يحتاج النظام إلى التعامل معها.

كيف تعمل Webhooks في Whats360؟

يمكن النظر إلى Webhooks كقناة اتصال بين نظامين. أحد النظامين ينتج Event، والنظام الآخر يستقبل هذا الحدث ويقرر ماذا سيفعل به.

في حالة Whats360 يمكن أن يبدأ الحدث من WhatsApp، أو يبدأ من متجر أو تطبيق أو نظام خارجي.

وبالتالي يمكن تصور البنية الأساسية بالشكل التالي:

هذا الاتجاه المزدوج هو الذي يجعل Webhook مفيدًا في بناء Integrations أكثر تعقيدًا من مجرد إرسال رسائل يدوية.

Outgoing Webhook: عندما يبدأ الحدث من WhatsApp

في نموذج Outgoing Webhook تبدأ العملية من Whats360.

على سبيل المثال، وصلت رسالة جديدة إلى رقم WhatsApp المتصل بالمنصة:

عند وقوع الحدث، يمكن إرسال تفاصيله إلى عنوان URL خارجي تحدده داخل النظام.

ويمكن أن تتضمن البيانات حقولًا مثل:

• phone لتحديد رقم الهاتف.
• message لمحتوى الرسالة.
• sender_name لاسم المرسل.
• instance_id لتحديد الجهاز أو الرقم داخل المنصة.
• message_id للتمييز بين الرسائل والأحداث.
• chat_jid لمعرف المحادثة.
• timestamp لتحديد وقت الحدث.
• media_url لرابط الوسائط عند وجودها.

يمكن أن يبدو Payload بشكل تقريبي هكذا:

{
  "phone": "+201234567890",
  "message": "أريد معرفة حالة الطلب",
  "sender_name": "Ahmed",
  "instance_id": "example",
  "message_id": "msg_123",
  "chat_jid": "201234567890@s.whatsapp.net",
  "timestamp": "2026-08-21T10:30:00Z",
  "media_url": null
}

لكن القيمة الحقيقية ليست في إرسال JSON فقط، بل في ما يستطيع النظام الخارجي فعله بهذه البيانات.

يمكن مثلًا استخدام رقم الهاتف للبحث عن العميل في CRM، ثم استخدام محتوى الرسالة لتحديد نوع الطلب، وبعد ذلك إنشاء Ticket أو تحديث Lead أو تشغيل Workflow.

Incoming Webhook: عندما يبدأ الحدث من نظام خارجي

في الاتجاه العكسي تبدأ العملية من متجر أو تطبيق أو CRM أو نظام داخلي.

مثلًا، قام عميل بإنشاء طلب جديد:

يمكن للنظام الخارجي إرسال بيانات مثل:

{
  "phone": "+201234567890",
  "message": "تم تأكيد طلبك رقم #1234",
  "name": "Ahmed"
}

بعد استقبال البيانات، يمكن استخدامها لإرسال رسالة WhatsApp إلى العميل المستهدف.

هذه الطريقة مفيدة في سيناريوهات التجارة الإلكترونية، مثل إرسال تأكيد للطلب، أو إشعار بالدفع، أو تحديث لحالة الشحنة، أو تشغيل رسالة متابعة بعد حدث معين.

ما الذي يوجد داخل Webhook Payload؟

بالنسبة للمطور، Payload هو الجزء الذي يحمل البيانات الفعلية للحدث.

على سبيل المثال، يمكن أن يحتوي Payload المرتبط بأحداث WhatsApp على مجموعة من الحقول التي تساعد النظام المستقبل على فهم الحدث:

الحقل	الاستخدام
phone	تحديد رقم الهاتف
message	محتوى الرسالة
sender_name	اسم المرسل
instance_id	تحديد الجهاز أو الرقم
message_id	تتبع الرسالة ومنع التكرار
chat_jid	تحديد المحادثة
timestamp	تحديد وقت الحدث
media_url	الوصول إلى الوسائط عند وجودها

المهم هنا أن المطور لا يتعامل مع Payload على أنه بيانات للعرض فقط. كل حقل يمكن أن يدخل في Business Logic.

مثلًا:

هذا التصميم يصبح مهمًا جدًا عندما يبدأ النظام في التعامل مع عدد كبير من الأحداث أو عندما تكون هناك احتمالية لإعادة إرسال Webhook.

ربط Shopify بـWhats360 عبر Webhook

في التجارة الإلكترونية، أحد الاستخدامات العملية للـWebhook هو ربط أحداث Shopify برسائل WhatsApp.

يمكن أن يبدأ التدفق من إنشاء الطلب:

ومن الأحداث التي يمكن استخدامها في هذا النوع من الربط:

• orders/create
• orders/updated
• orders/paid
• customers/create

وقد يحتوي Payload القادم من Shopify على بيانات مثل:

{
  "id": 820982911946154508,
  "order_number": 1234,
  "total_price": "199.00",
  "customer": {
    "first_name": "Ahmed",
    "phone": "+201234567890"
  }
}

يمكن للنظام بعد ذلك استخراج رقم العميل ورقم الطلب وقيمة الطلب واستخدام هذه البيانات في رسالة WhatsApp أو Workflow آخر.

التحقق من Webhook القادم من Shopify

التكامل الاحترافي لا يعتمد على استقبال أي Request لمجرد وصوله إلى Endpoint.

في تكاملات Shopify يمكن استخدام هيدر X-Shopify-Hmac-SHA256 للتحقق من مصدر الطلب باستخدام Secret وفق آلية Shopify.

وهذا يقود إلى قاعدة عامة مهمة في تصميم Webhooks:

ربط WooCommerce بـWhats360

يمكن تطبيق النموذج نفسه مع WooCommerce، حيث يمكن أن تصبح أحداث المتجر Triggers لإرسال إشعارات عبر WhatsApp.

ومن أمثلة الأحداث التي يمكن ربطها:

• إنشاء طلب.
• تحديث طلب.
• إنشاء عميل.
• تحديث منتج.

يمكن أن تكون النتيجة مثلًا رسالة تلقائية بعد إنشاء الطلب:

تم استلام طلبك بنجاح، وسيتم تحديثك بحالة الطلب عند حدوث أي تغيير.

لكن سيناريو الاستخدام يمكن أن يكون أكثر تعقيدًا من ذلك. فقد يصل الحدث إلى نظام وسيط يقوم بفحص قيمة الطلب، وتحديد نوع العميل، ثم اختيار رسالة مختلفة بناءً على حالة الطلب.

أهمية HTTP 200 وLogs

عند تشخيص مشكلة في Webhook يجب معرفة ما إذا كان النظام المرسل حصل على الاستجابة التي يتوقعها.

في كثير من تكاملات Webhook يكون HTTP 200 OK جزءًا مهمًا من تأكيد نجاح استقبال الطلب.

كما أن Logs تساعد في تحديد المرحلة التي حدثت فيها المشكلة:

• هل تم إرسال Request؟
• هل وصل إلى Endpoint؟
• هل تم قبوله؟
• هل تم التحقق من Secret؟
• هل تم تحليل JSON؟
• هل تم تنفيذ الإجراء المطلوب؟

n8n + Whats360: عندما يصبح Webhook نقطة دخول إلى Workflow

إذا كان المطلوب تنفيذ أكثر من إجراء بعد وصول الحدث، فقد يكون من المفيد استخدام منصة Automation مثل n8n.

في هذه الحالة لا يكون Webhook هو نهاية العملية، بل هو نقطة دخول إلى Workflow.

يمكن مثلًا استقبال رسالة WhatsApp في n8n، ثم البحث عن رقم العميل في قاعدة بيانات، وبعد ذلك تحديث CRM وإرسال تنبيه داخلي أو تنفيذ طلب إلى API آخر.

وهذا يفتح الباب لبناء سيناريوهات Automation دون الحاجة إلى كتابة Backend كامل لكل عملية بسيطة.

أما إذا أصبحت قواعد العمل معقدة جدًا، فقد يكون التطوير المخصص أكثر ملاءمة، خصوصًا عند الحاجة إلى إدارة دقيقة للبيانات والأخطاء والتكرار والصلاحيات.

ما الفرق بين Webhook وHookURL في Whats360؟

قد تبدو المصطلحات متشابهة، لكن هناك فرق وظيفي مهم.

Webhook هو آلية اتصال تعتمد على HTTP Requests لنقل Events بين الأنظمة.

أما HookURL فهو رابط استقبال مخصص في Whats360 يمكن ربطه بجهاز أو رقم WhatsApp محدد.

العنصر	Webhook	HookURL
الفكرة	آلية Event Communication	رابط استقبال مخصص
الاستخدام	Integration وAutomation	استقبال أحداث مباشرة
الربط بالجهاز	حسب إعداد التكامل	مرتبط بجهاز محدد
الأمان	حسب التكامل	يمكن استخدام X-Hook-Secret
أفضل استخدام	ربط الأنظمة والـWorkflows	توجيه أحداث إلى رقم محدد

إذن HookURL ليس مجرد اسم آخر لـWebhook، وإنما طريقة عملية لإنشاء نقطة استقبال مرتبطة بجهاز معين.

كيف تستخدم HookURL في سيناريو متجر؟

لنفترض أن لديك متجرًا على Shopify أو Salla أو Zid أو تطبيقًا مخصصًا، وتريد توجيه الأحداث إلى رقم WhatsApp محدد.

عند إنشاء HookURL يمكن أن تتضمن العملية اختيار الجهاز أو الرقم، ثم إعطاء الرابط اسمًا يوضح الغرض منه، مثل ربط طلبات Shopify أو تنبيهات الطلبات.

بعد ذلك يمكن استخدام الرابط داخل النظام الخارجي لإرسال البيانات إليه.

حماية HookURL باستخدام Secret

من إعدادات HookURL يمكن استخدام Secret مخصص يتم إرساله عبر Header مثل:

X-Hook-Secret: your-secret-value

وبذلك يمكن إضافة طبقة تحقق تمنع قبول الطلبات التي لا تحتوي على قيمة Secret المطلوبة.

كما توفر إدارة HookURL إمكانية التعامل مع الرابط نفسه، مثل تفعيله أو إيقافه أو حذفه، بالإضافة إلى مراقبة الطلبات الواردة.

أمان Webhooks: لا تجعل Endpoint مجرد باب مفتوح

إنشاء Webhook يعمل في الاختبار لا يعني أن تصميمه أصبح مناسبًا للإنتاج.

عند بناء Integration حقيقي، يجب التفكير في طبقة الأمان منذ البداية.

HTTPS

استخدم اتصالًا مشفرًا عند نقل البيانات بين الأنظمة، خصوصًا عندما تتضمن البيانات أرقام هواتف أو بيانات طلبات أو معلومات مرتبطة بالعملاء.

Authorization

يمكن استخدام Headers مخصصة للمصادقة، مثل:

Authorization: Bearer <Token>

بحسب آلية التكامل والطرف الذي يرسل البيانات.

HMAC

عندما يستخدم النظام توقيعًا مبنيًا على Secret، يمكن للطرف المستقبل التحقق من أن الطلب جاء من المصدر المتوقع وأن محتواه لم يتم تغييره وفق آلية التوقيع المستخدمة.

X-Hook-Secret

في HookURL يمكن استخدام Secret مخصص داخل Header مثل X-Hook-Secret لإضافة طبقة تحقق إضافية.

Validation

حتى بعد اجتياز المصادقة، يجب فحص البيانات قبل إدخالها في Business Logic.

هل رقم الهاتف موجود؟ هل الحقول المطلوبة موجودة؟ هل صيغة JSON صحيحة؟ هل القيمة المتوقعة للحدث صحيحة؟ وهل البيانات متوافقة مع العملية التي سيقوم بها النظام؟

Idempotency وDuplicate Events: ماذا لو وصل الحدث مرتين؟

هذه النقطة مهمة جدًا عند الانتقال من تجربة بسيطة إلى نظام Production.

افترض أن المتجر أرسل Event لإنشاء طلب:

إذا قام النظام بإرسال رسالة WhatsApp في كل مرة دون فحص، فقد يحصل العميل على نفس الرسالة أكثر من مرة.

هنا يأتي مفهوم Idempotency، أي تصميم عملية المعالجة بحيث لا يؤدي تكرار نفس الحدث إلى تنفيذ العملية نفسها بشكل غير مرغوب فيه.

يمكن استخدام معرف مناسب مثل:

• event_id
• message_id
• order_id

ثم تخزين الأحداث التي تمت معالجتها.

هذه الفكرة ليست مرتبطة بـWhats360 وحدها، وإنما هي مبدأ مهم في تصميم أنظمة Webhook الموثوقة عمومًا.

ماذا تفعل عندما لا يصل Webhook؟

عند توقف التكامل، الخطأ الشائع هو تغيير عدة إعدادات في الوقت نفسه دون تحديد مكان المشكلة.

الأفضل استخدام مسار تشخيص واضح يبدأ من المصدر وينتهي بالإجراء.

إذا لم يصل Request أصلًا، فلا معنى للبحث داخل Business Logic.

إذا وصل Request لكنه فشل في Authentication، فالمشكلة في طبقة المصادقة.

إذا وصل JSON لكنه لم يحتوِ على الحقول التي يحتاج إليها النظام، فقد تكون المشكلة في Payload أو Field Mapping.

وإذا تم كل ذلك بنجاح ولكن لم يتم إرسال رسالة WhatsApp، فيجب الانتقال إلى طبقة تنفيذ الإجراء نفسها.

Webhook أم API أم n8n أم Integration جاهز؟

ليس كل مشروع يحتاج إلى الحل نفسه. اختيار التقنية المناسبة يعتمد على طبيعة العملية التي تريد تنفيذها.

متى تستخدم Webhook؟

استخدم Webhook عندما تريد أن يبدأ إجراء تلقائي بمجرد وقوع Event.

مثال:

متى تستخدم API؟

يكون API مناسبًا عندما يحتاج نظامك إلإى إرسال Request لتنفيذ عملية أو الحصول على بيانات عند الطلب.

متى تستخدم n8n؟

استخدم n8n عندما تحتاج إلى Workflow متعدد الخطوات يمكن ربطه بخدمات وقواعد بيانات وAPIs مختلفة دون بناء كل طبقة برمجية من الصفر.

متى تستخدم Integration جاهزًا؟

إذا كان السيناريو الذي تحتاجه مدعومًا بالفعل، فإن التكامل الجاهز قد يكون أسرع وأبسط من بناء نظام مخصص.

متى تحتاج إلى Custom Integration؟

عندما يصبح المشروع أكثر تعقيدًا ويحتاج إلى Business Logic خاص، أو Database، أو عدة APIs، أو Authentication مخصص، أو معالجة متقدمة للبيانات، أو Logging، أو Retry Strategy، أو Deduplication.

الحل	الاستخدام الأنسب
Webhook	التعامل مع Events فور وقوعها
API	تنفيذ عمليات أو طلب بيانات عند الحاجة
n8n	بناء Workflows متعددة الخطوات
Integration جاهز	السيناريوهات الشائعة والمدعومة
Custom Integration	Business Logic والأنظمة المعقدة

أهم استخدامات Webhooks مع Whats360

أتمتة التجارة الإلكترونية

يمكن تحويل أحداث المتجر إلى رسائل WhatsApp تلقائية.

وهذا يمكن أن يشمل تأكيد الطلب أو تحديث حالته أو إشعار العميل بحدث جديد، حسب تصميم النظام.

متابعة Leads

يمكن استخدام Webhook أو Automation Layer لتمرير بيانات Lead إلى Whats360 وتشغيل تواصل تلقائي معه.

ربط CRM مع WhatsApp

يمكن نقل أحداث المحادثات إلى CRM، أو استخدام أحداث CRM لبدء رسائل WhatsApp، وفق تصميم التكامل.

ربط ERP

يمكن أن تصبح أحداث الفواتير أو الطلبات أو تحديثات النظام الداخلي Triggers لإرسال إشعارات للعميل.

خدمة العملاء

يمكن نقل الرسائل والأحداث إلى أنظمة Ticketing أو CRM لمساعدة فريق الدعم في متابعة المحادثات من داخل منظومة العمل.

متى تحتاج إلى مطور لبناء التكامل؟

يمكن تنفيذ العديد من السيناريوهات البسيطة من خلال Integrations جاهزة أو أدوات Automation.

لكن عندما تتوسع البنية، قد يصبح التطوير المخصص هو الخيار الأنسب.

تخيل مثلًا البنية التالية:

هنا لم تعد المشكلة مجرد إنشاء Webhook.

أصبحت لديك Integration Architecture تحتاج إلى تصميم قواعد العمل، والمصادقة، والتعامل مع الأخطاء، ومنع التكرار، وتسجيل الأحداث، وربما إدارة الطوابير والعمليات غير المتزامنة.

عند الحاجة إلى هذا المستوى من البرمجة المخصصة يمكن الاستعانة بفريق مثل Beincode لبناء طبقة التكامل المناسبة حسب النظام المطلوب.

البنية المثالية لتكامل WhatsApp داخل نظام SaaS

يمكن النظر إلى WhatsApp باعتباره جزءًا من منظومة SaaS بدل التعامل معه كقناة منفصلة.

وفي الاتجاه العكسي يمكن أن تنتقل رسائل العملاء من WhatsApp إلى طبقة التكامل ثم إلى CRM أو قاعدة بيانات أو نظام داخلي.

وهنا تظهر الصورة الأهم: Webhook ليس المنتج النهائي، بل طبقة اتصال داخل منظومة أكبر.

كيف تبدأ أول Integration بدون تعقيد؟

قبل كتابة أي كود، حدد طبيعة العملية التي تريد بناءها.

عندما تكون هذه الإجابات واضحة قبل التنفيذ، يصبح تصميم التكامل أسهل بكثير.

Webhooks من مجرد رابط إلى Integration Architecture

في أبسط صورة يمكن أن يبدو Webhook هكذا:

لكن في نظام أكثر نضجًا، تصبح العملية:

وهذا هو الفرق بين تكامل يعمل في تجربة سريعة وبين Integration تم تصميمه ليكون جزءًا من منظومة تشغيل حقيقية.

كيف تختار تصميم Webhook المناسب؟

ابدأ دائمًا من العملية وليس من الأداة.

إذا كان لديك Event وتريد تنفيذ Action فور وقوعه، فكر في Webhook.

إذا كان لديك نظام يحتاج إلى استدعاء عملية عند الطلب، فكر في API.

إذا كان لديك Workflow متعدد الخطوات بين عدة خدمات، فكر في Automation Platform مثل n8n.

إذا كان السيناريو معروفًا ومدعومًا، استخدم Integration جاهزًا.

إذا كان لديك Business Logic معقد، ففكر في Custom Integration.

بهذه الطريقة لا تصبح التقنية هدفًا في حد ذاتها، وإنما تصبح وسيلة لحل المشكلة التشغيلية.

مقالات ذات صلة

• دليل Whats360 وWebhook وAPI
• ربط WhatsApp مع CRM
• أتمتة WhatsApp والـWorkflows
• ربط Shopify مع WhatsApp
• ربط WooCommerce مع WhatsApp
• n8n وWhatsApp Automation

أسئلة شائعة حول Webhooks وHookURL في Whats360

الخلاصة

Webhooks في Whats360 ليست مجرد وسيلة لإرسال JSON من نظام إلى آخر، وإنما يمكن استخدامها كجزء من بنية Event-driven تربط WhatsApp بالمتاجر والـCRM والـERP وقواعد البيانات وأدوات الأتمتة والتطبيقات المخصصة.

يمكن أن يبدأ التدفق من WhatsApp:

أو يبدأ من المتجر:

أما HookURL فيوفر نموذجًا عمليًا لاستقبال الأحداث من الأنظمة الخارجية وتوجيهها إلى جهاز WhatsApp محدد، مع إمكانية إضافة طبقة تحقق باستخدام Secret.

لكن بناء Integration موثوق لا يتوقف عند إنشاء الرابط. يجب التفكير أيضًا في Authentication وValidation وHTTP Responses وRetry وIdempotency وLogging وMonitoring.

وعندما تتعامل مع Webhook بهذه الطريقة، فأنت لا تقوم فقط بربط WhatsApp بمتجر أو CRM، بل تبني طبقة اتصال تسمح بتحويل الأحداث التي تحدث داخل أنظمتك إلى عمليات تلقائية في الوقت المناسب.

إذا كنت تستخدم Whats360 بالفعل، فالخطوة التالية ليست إنشاء Webhook بشكل عشوائي، وإنما تحديد الـEvents التي تريد نقلها، والـPayload الذي تحتاج إليه، والـWorkflow الذي يجب أن يبدأ بعد وصول الحدث.

ومن هنا يمكن أن ينتقل المشروع من تكامل بسيط لإرسال رسالة إلى منظومة WhatsApp Automation قابلة للتوسع والمراقبة والربط مع الأنظمة البرمجية.

هل لديك نظام تريد ربطه بواتساب؟ يمكنك إرسال تفاصيل النظام والحدث الذي تريد تشغيله، مثل إنشاء طلب أو وصول Lead أو تحديث حالة عميل، لتحديد أنسب طريقة للتكامل.

ناقش سيناريو التكامل