Webhook في Whats360: كيف تربط WhatsApp بالمتاجر وCRM والأنظمة البرمجية وتبني أتمتة فورية؟

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

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

يمكن أن يصبح المسار مثلًا:

Shopify → Webhook → Whats360 → WhatsApp → العميل

أو في الاتجاه المعاكس:

Whats360 → Webhook → CRM → فريق المبيعات

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

ما هو Webhook ولماذا تحتاجه الأنظمة التي تعتمد على WhatsApp؟

الـWebhook هو آلية تعتمد على HTTP تسمح لنظام بإرسال بيانات إلى نظام آخر تلقائيًا عند وقوع حدث محدد، بدل أن يظل النظام الآخر يستعلم عن وجود بيانات جديدة بشكل دوري.

بمعنى أبسط، بدل أن تسأل النظام كل فترة:

هل حدث شيء جديد؟

يمكن للنظام أن يقول لك مباشرة:

حدث شيء جديد، وهذه هي البيانات الخاصة به.

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

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

إذا كان الهدف إرسال رسالة WhatsApp للعميل، يمكن أن يصبح التدفق:

إنشاء الطلب → إرسال Webhook → استقبال البيانات → تحديد رقم العميل → إنشاء رسالة → إرسال WhatsApp

وهكذا يتحول Webhook من مجرد تقنية لنقل البيانات إلى جزء أساسي من Workflow كامل.

كيف يعمل Webhook في Whats360؟

يمكن فهم Webhook داخل Whats360 من خلال اتجاهين رئيسيين لتدفق البيانات.

الاتجاه الأول يبدأ من WhatsApp أو Whats360 ويتجه إلى نظام خارجي.

أما الاتجاه الثاني فيبدأ من نظام خارجي ويتجه إلى Whats360، ثم يمكن أن ينتهي بإرسال رسالة إلى عميل على WhatsApp.

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

Outgoing Webhook: من Whats360 إلى النظام الخارجي

في هذا السيناريو يكون Whats360 هو مصدر الحدث، ويقوم بإرسال البيانات إلى Endpoint خارجي يحدده المستخدم.

مثلًا، عند وصول رسالة جديدة من عميل، يمكن أن يتم إرسال بيانات الحدث إلى نظام CRM أو منصة أتمتة أو خادم خاص.

يمكن تصور المسار بهذه الصورة:

عميل → WhatsApp → Whats360 → Webhook → النظام الخارجي

ومن أمثلة الأحداث التي يمكن التعامل معها وفق إعدادات المنصة:

• رسالة واردة.
• رسالة مرسلة.
• فشل إرسال.
• أحداث مرتبطة بالاشتراك.

وبهذه الطريقة يمكن تحويل محادثة WhatsApp إلى Event يمكن لنظام آخر التعامل معه.

مثلًا:

رسالة عميل جديدة → Whats360 → Webhook → CRM → إنشاء أو تحديث سجل العميل.

Incoming Webhook: من النظام الخارجي إلى Whats360

في الاتجاه الآخر يكون النظام الخارجي هو الذي يرسل البيانات إلى Whats360.

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

يمكن أن يكون المسار:

المتجر → Webhook → Whats360 → WhatsApp → العميل

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

ومن هنا يمكن تحويل الأحداث التجارية إلى رسائل تلقائية دون الحاجة إلى أن يقوم الموظف بفتح لوحة التحكم وإرسال الرسالة يدويًا في كل مرة.

Incoming أم Outgoing Webhook؟

الاحتياج	الاتجاه المناسب	مثال
إرسال أحداث WhatsApp إلى نظام آخر	Outgoing	إرسال رسالة العميل إلى CRM
إرسال طلب متجر إلى WhatsApp	Incoming	تأكيد الطلب تلقائيًا
إرسال الرسائل الواردة إلى n8n	Outgoing	بدء Workflow داخل n8n
إرسال إشعار دفع للعميل	Incoming	بوابة الدفع → Whats360
مزامنة المحادثات مع نظام خارجي	Outgoing	Whats360 → CRM

القاعدة العملية بسيطة: إذا كان الحدث يحدث داخل Whats360 وتريد إخبار نظام خارجي به، فأنت تفكر في Outgoing Webhook. وإذا كان الحدث يحدث خارج Whats360 وتريد إدخاله إلى Whats360، فأنت تفكر في Incoming Webhook.

ما البيانات التي تنتقل داخل Webhook Payload؟

لا تكفي معرفة أن Webhook يرسل بيانات؛ يجب أن تفهم شكل البيانات التي تنتقل داخل الطلب.

غالبًا يتم استخدام JSON باعتباره تنسيقًا مناسبًا للتعامل بين التطبيقات والأنظمة البرمجية.

ومن المتغيرات التي يمكن أن تظهر ضمن بيانات Webhook في السيناريوهات المعنية:

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

فكرة الـPayload مهمة لأنها تمثل المادة الخام التي سيستخدمها النظام المستلم.

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

مثلًا، يمكن أن يكون المنطق:

phone → تحديد العميل

message → تحليل المحتوى

message_id → تتبع الحدث

timestamp → تسجيل وقت العملية

media_url → معالجة المرفق

وهذا هو الفرق بين مجرد نقل البيانات وبين تصميم تكامل مفيد.

بناء Workflow عملي من الحدث إلى رسالة WhatsApp

لنفترض أن متجرًا يستقبل طلبات جديدة، ويريد إرسال رسالة تأكيد تلقائية للعميل.

بدل أن يكون Workflow يدويًا:

طلب جديد → موظف يراجع الطلب → يبحث عن رقم العميل → يفتح WhatsApp → يكتب الرسالة → يرسلها

يمكن بناء تدفق آلي:

Order Created → Webhook → Whats360 → Customer Phone → WhatsApp Message

الخطوة الأولى هي وقوع الحدث، مثل إنشاء الطلب.

بعد ذلك يتم إرسال بيانات الطلب إلى Webhook.

يتم استقبال البيانات وتحديد الحقول المهمة، مثل رقم العميل ورقم الطلب والمعلومات التي يحتاج إليها سيناريو الرسالة.

بعدها يتم تمرير البيانات إلى طبقة WhatsApp، حيث يمكن استخدام الرقم والنص المناسب لإرسال الإشعار.

القيمة هنا ليست فقط في سرعة الإرسال، وإنما في تحويل Workflow متكرر إلى عملية يمكن للنظام تنفيذها بصورة منظمة.

ربط Shopify بـWhats360 عبر Webhook

عند استخدام Shopify مع Webhook، يصبح المتجر مصدرًا للأحداث، بينما يمكن أن يكون Whats360 طبقة إرسال الرسائل عبر WhatsApp.

التصور العام:

Shopify → Webhook URL → Whats360 → WhatsApp

يمكن أن تبدأ العملية بإنشاء Webhook استقبال داخل Whats360، ثم الحصول على رابط الاستقبال المناسب.

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

من الأحداث الشائعة التي يمكن استخدامها في هذا النوع من التكامل:

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

يمكن أن يحتوي Payload القادم من المتجر على معلومات مثل رقم الطلب والقيمة وبيانات العميل.

مثال مبسط:

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

بعد وصول البيانات، تأتي مرحلة Field Mapping، أي تحديد أي حقل سيتم استخدامه في الرسالة وأي بيانات سيتم تجاهلها.

وهنا يجب الانتباه إلى أن التكامل الناجح لا يعني فقط وصول HTTP Request؛ بل يجب أيضًا أن تكون البيانات متوافقة مع المنطق الذي سيستخدمها.

الأمان عند ربط Shopify والأنظمة الخارجية

عند التعامل مع Webhooks من منصات خارجية، لا ينبغي افتراض أن أي Request يصل إلى Endpoint يمكن الوثوق به تلقائيًا.

بعض المنصات تستخدم آليات للتحقق من مصدر الطلب، ومن الأمثلة المعروفة في Shopify استخدام ترويسة مثل X-Shopify-Hmac-SHA256 للتحقق من الطلبات باستخدام مفتاح سري.

المبدأ العام مهم حتى عندما تختلف طريقة التنفيذ من منصة إلى أخرى:

استقبل البيانات، ثم تحقق من مصدرها قبل الاعتماد عليها في عملية حساسة.

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

ربط WooCommerce مع Whats360

يمكن تطبيق الفكرة نفسها على WooCommerce.

المسار يصبح:

WooCommerce → Webhook → Whats360 → WhatsApp

يمكن إنشاء Webhook من إعدادات WooCommerce، ثم تحديد الحدث المطلوب ووضع Delivery URL الخاص بالاستقبال وإعداد Secret عند الحاجة.

من أمثلة الأحداث التي يمكن التعامل معها:

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

ويمكن أن يحتوي Payload على بيانات مثل:

{
  "id": 727,
  "status": "processing",
  "total": "150.00",
  "billing": {
    "first_name": "Sara",
    "phone": "+966501234567"
  }
}

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

ومن المهم أيضًا مراقبة Logs الخاصة بالتكامل عند حدوث مشكلة، لأن معرفة أن الطلب لم يصل تختلف تمامًا عن معرفة أنه وصل ولكن فشل أثناء معالجة البيانات.

Webhook مع n8n: عندما تحتاج إلى Automation أكبر

القوة الحقيقية للـWebhook تظهر عندما لا يكون المطلوب مجرد إرسال رسالة واحدة، وإنما بناء سلسلة من الإجراءات.

هنا يمكن استخدام n8n كطبقة لتنظيم الـWorkflow.

مثلًا:

Whats360 → n8n Webhook Trigger → Condition → CRM / Google Sheets / Email / Database

عند وصول رسالة إلى Whats360، يمكن إرسال الحدث إلى Webhook داخل n8n.

بعد ذلك يستطيع Workflow اتخاذ قرار بناءً على البيانات.

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

الميزة هنا أن Webhook يقوم بدور ناقل الحدث، بينما n8n يقوم بدور منسق Workflow.

وهذا يوضح نقطة مهمة: Webhook وAutomation Platform ليسا الشيء نفسه.

Webhook يخبر النظام بأن حدثًا وقع وينقل البيانات، بينما منصة الأتمتة يمكن أن تحدد ماذا يجب أن يحدث بعد ذلك.

Webhook مع Make وZapier وCRM

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

يمكن أن يكون السيناريو:

Whats360 → Webhook → Automation Platform → CRM

أو:

CRM / Automation → Webhook → Whats360 → WhatsApp

وهنا تصبح Webhook طبقة اتصال بين الأنظمة بدل أن يكون كل نظام معزولًا عن الآخر.

في بيئة Odoo أو Zoho CRM أو HubSpot مثلًا، يمكن أن يكون الهدف تسجيل المحادثات أو الأحداث في النظام الخارجي، بينما يمكن أن يكون الاتجاه العكسي مفيدًا عند الحاجة إلى إرسال إشعارات إلى العميل بناءً على حدث داخل CRM.

الاختيار الصحيح يعتمد على نقطة البداية والنتيجة المطلوبة.

Webhook مع أنظمة المتاجر وبيئات التجارة الإلكترونية

لا تقتصر الفكرة على Shopify وWooCommerce فقط.

يمكن أن تدخل Webhooks في منظومة أوسع تضم منصات مثل Salla وZid، إلى جانب أدوات أخرى تستخدمها المتاجر لإدارة الطلبات والعملاء والمدفوعات والشحن.

الفكرة المشتركة هي:

حدث داخل النظام → إرسال بيانات → استقبال البيانات → اتخاذ إجراء.

قد يكون الإجراء إرسال رسالة تأكيد، أو تحديث عميل، أو بدء Workflow، أو تسجيل الحدث في نظام آخر.

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

كيف تؤمّن Webhook؟

الأمان ليس مرحلة إضافية يمكن التفكير فيها بعد انتهاء التكامل؛ بل يجب أن يكون جزءًا من التصميم من البداية.

استخدم HTTPS

عند تبادل بيانات حساسة بين الأنظمة، يجب أن يكون الاتصال مؤمنًا عبر HTTPS عندما يكون ذلك مناسبًا ومتاحًا.

استخدم Secret أو آلية تحقق مناسبة

وجود Secret أو آلية Authentication يسمح للنظام المستلم بالتحقق من الطلب بدل التعامل مع كل Request باعتباره موثوقًا.

تحقق من مصدر الطلب

إذا كانت المنصة الخارجية توفر آلية تحقق مثل HMAC، فيجب الاستفادة منها بالطريقة الصحيحة بدل الاكتفاء باستقبال البيانات.

لا تثق في Payload قبل التحقق

البيانات القادمة من نظام خارجي يجب التعامل معها كمدخلات تحتاج إلى Validation قبل استخدامها في العمليات المهمة.

ماذا يحدث إذا فشل Webhook؟

أي تكامل حقيقي يجب أن يفترض أن الفشل ممكن.

قد يتوقف السيرفر المستلم مؤقتًا، أو يحدث Timeout، أو يكون Endpoint غير متاح، أو تصل البيانات بشكل غير متوقع.

لذلك تظهر أهمية Retry Mechanism.

يمكن أن يكون التصور:

Request → Failure → Retry → Retry → Retry

وفي إعدادات Webhook يمكن أن توجد خيارات لتحديد عدد المحاولات والفاصل الزمني بينها، وفق الإمكانيات المتاحة في النظام.

وجود Retry لا يعني أن المشكلة اختفت؛ بل يعني أن النظام لديه فرصة إضافية لتسليم الحدث.

وهنا تظهر أهمية Logging، لأنك تحتاج إلى معرفة:

• هل تم إرسال الطلب؟
• هل وصل إلى السيرفر؟
• هل حدث Timeout؟
• ما Response الذي عاد؟
• هل تمت إعادة المحاولة؟
• هل تمت معالجة الحدث أكثر من مرة؟

لماذا يجب التفكير في Duplicate Events وIdempotency؟

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

إذا كان Workflow ينفذ عملية حساسة عند كل Request، فقد يؤدي تكرار الحدث إلى تنفيذ الإجراء مرتين.

مثلًا، إذا كان حدث إنشاء الطلب يطلق رسالة WhatsApp، فإن إعادة معالجة نفس الحدث دون آلية مناسبة قد تؤدي إلى إرسال الرسالة أكثر من مرة.

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

وجود معرف مثل message_id أو معرف حدث أو معرف عملية يمكن أن يساعد في بناء منطق مناسب لمنع المعالجة المكررة حسب تصميم النظام.

هذه النقطة غالبًا ما تكون غائبة عن الشروحات السطحية للـWebhook، لكنها من التفاصيل التي تهم أي مشروع ينتقل من التجربة إلى Production.

أين تفشل تكاملات Webhook عادةً؟

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

Endpoint غير متاح

إذا كان السيرفر المستلم متوقفًا أو الرابط غير صحيح، فلن تتمكن البيانات من الوصول إلى التطبيق.

Timeout

قد يصل الطلب إلى السيرفر، لكن المعالجة تستغرق وقتًا أطول من الوقت المتوقع للاستجابة.

Payload غير متوقع

قد تصل البيانات بتنسيق مختلف عما يتوقعه النظام، مما يؤدي إلى فشل المعالجة.

Field Mapping خاطئ

قد يصل رقم الهاتف، لكن النظام يبحث عنه داخل حقل مختلف أو يتوقع اسمًا مختلفًا للحقل.

Secret غير صحيح

إذا كان التحقق من المصدر يعتمد على Secret غير متطابق، يمكن رفض الطلب حتى لو كان Endpoint صحيحًا.

Response غير مناسب

بعض الأنظمة تعتمد على Response محدد لتعتبر عملية التسليم ناجحة.

Workflow غير مفعل

قد تكون كل الإعدادات صحيحة، لكن Workflow أو Webhook نفسه غير نشط.

تكرار الحدث

إعادة المحاولة قد تجعل النظام يعالج الحدث أكثر من مرة إذا لم يكن Workflow مصممًا للتعامل مع ذلك.

Webhook أم API أم Automation Platform؟

من أكثر الأخطاء شيوعًا التعامل مع Webhook وAPI وAutomation Platform باعتبارها تقنيات متنافسة يجب اختيار واحدة منها.

في الحقيقة، كل طبقة تؤدي وظيفة مختلفة.

التقنية	الدور الأساسي	مثال
Webhook	نقل الأحداث تلقائيًا	إرسال حدث رسالة جديدة إلى CRM
API	تنفيذ طلب أو عملية برمجية	طلب إرسال رسالة من نظام برمجي
Automation Platform	تنسيق عدة خطوات	n8n أو Make أو Zapier
CRM	إدارة العملاء والبيانات والفرص	إدارة محادثة العميل داخل سجل CRM
WhatsApp	قناة التواصل	إرسال واستقبال رسائل العملاء

لهذا قد تكون البنية الاحترافية:

Webhook + API + Automation + CRM + WhatsApp

بدل محاولة استخدام تقنية واحدة لتنفيذ كل شيء.

كيف تصمم Webhook Architecture قابلة للتوسع؟

في مشروع صغير قد يكفي ربط نظامين مباشرة:

System A → Whats360

لكن مع نمو المشروع، قد تحتاج إلى أكثر من مصدر وأكثر من إجراء.

عندها يمكن التفكير في Architecture أكثر تنظيمًا:

Sources

↓

Webhook Layer

↓

Validation

↓

Field Mapping

↓

Automation

↓

Whats360

↓

WhatsApp

↓

CRM / Analytics

الميزة في هذا التصميم أنه يجعل كل طبقة مسؤولة عن وظيفة واضحة.

مصدر البيانات ينتج الحدث.

طبقة Webhook تنقل الحدث.

Validation تتحقق من البيانات.

Mapping يحول الحقول إلى الشكل المطلوب.

Automation يحدد الإجراء.

Whats360 يتولى طبقة WhatsApp ضمن السيناريو.

ثم يمكن إرسال المعلومات إلى CRM أو نظام تحليلات عند الحاجة.

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

سيناريوهات عملية لاستخدام Webhook مع WhatsApp

تأكيد طلب جديد

New Order → Webhook → Whats360 → WhatsApp

عند إنشاء الطلب، تصل البيانات إلى Whats360 ويتم استخدام رقم العميل لإرسال رسالة مناسبة.

إشعار الدفع

Payment Success → Webhook → Whats360 → WhatsApp

عند نجاح عملية الدفع، يمكن أن يبدأ Workflow لإجراء لبدء Workflow لإرسال إشعار للعميل وفق إعدادات النظام.

تحديث حالة الشحن

Shipping Event → Webhook → Whats360 → WhatsApp

يمكن استخدام تحديث الحالة كـTrigger لرسالة مرتبطة بالطلب.

مزامنة الرسائل مع CRM

WhatsApp Message → Whats360 → Outgoing Webhook → CRM

هنا يتحول حدث WhatsApp إلى بيانات يمكن للنظام الخارجي استخدامها في سجل العميل.

Automation عبر n8n

Whats360 → n8n → Conditions → Actions

يمكن أن يؤدي حدث واحد إلى عدة إجراءات وفق قواعد الـWorkflow.

ربط أنظمة متعددة

Store → Webhook → Automation → Whats360 → CRM

وهنا يصبح Webhook جزءًا من منظومة متكاملة بدل أن يكون مجرد اتصال بين نظامين.

متى يكون Webhook هو الحل المناسب؟

يكون Webhook مناسبًا عندما يكون لديك حدث تريد أن يستجيب له نظام آخر تلقائيًا.

اسأل نفسك:

• هل أريد معرفة الحدث فور وقوعه؟
• هل النظام المصدر يستطيع إرسال HTTP Request؟
• هل لدي Endpoint لاستقبال البيانات؟
• هل أحتاج إلى تشغيل Workflow بناءً على الحدث؟
• هل البيانات التي تصل كافية لتنفيذ الإجراء المطلوب؟

إذا كانت الإجابة نعم، فقد يكون Webhook جزءًا مناسبًا من الحل.

أما إذا كنت تحتاج إلى أن يطلب نظامك بيانات أو ينفذ عملية محددة بشكل برمجي، فقد تحتاج إلى API.

وإذا كانت العملية تتضمن عدة شروط وإجراءات بين أنظمة مختلفة، فقد تحتاج إلى Automation Platform إلى جانب Webhook.

Webhook داخل Whats360

تضع Whats360 Webhook داخل طبقة التكامل بين WhatsApp والأنظمة الخارجية.

ومن المعلومات التشغيلية المرتبطة بالمنظومة وجود إمكانية إدارة Webhooks، والتعامل مع Incoming وOutgoing، واستخدام Payload بصيغة JSON، إلى جانب إعدادات مرتبطة بالأمان وإعادة المحاولة وقوالب التكامل.

ويمكن الوصول إلى قسم Webhooks من:

إدارة Webhooks في Whats360

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

على سبيل المثال:

ما الحدث؟ طلب جديد.

أين يحدث؟ المتجر.

إلى أين تذهب البيانات؟ Whats360.

ما الإجراء؟ إرسال رسالة WhatsApp.

أو:

ما الحدث؟ رسالة جديدة.

أين يحدث؟ WhatsApp.

إلى أين تذهب البيانات؟ CRM.

ما الإجراء؟ تسجيل المحادثة أو بدء Workflow.

قوالب التكامل تختصر نقطة البداية

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

ومن أمثلة السيناريوهات التي يمكن أن تدخل ضمن مكتبة قوالب Webhook:

• Shopify.
• WooCommerce.
• Custom Webhook.
• Odoo.
• Salla.
• Zid.
• EasyOrders.
• YouCan.
• Meta Lead Ads.
• Google Sheets وForms.
• Payment Gateways.
• Make وZapier.
• Zoho CRM وHubSpot.
• توجيه الوسائط والملفات.

القيمة الحقيقية في هذه القوالب ليست في عددها، وإنما في تقليل الوقت اللازم للوصول إلى نقطة البداية الصحيحة.

ومع ذلك، يجب أن يظل التصميم مرتبطًا بالـWorkflow الفعلي. فالقالب لا يلغي الحاجة إلى فهم البيانات التي تنتقل، والحقول المطلوبة، وطريقة المصادقة، وما يجب أن يحدث عند الفشل.

Checklist قبل تشغيل Webhook في Production

• تأكد من صحة Endpoint.
• استخدم HTTPS عندما يكون مناسبًا.
• حدد طريقة Authentication أو Secret.
• افهم شكل Payload المتوقع.
• تحقق من Field Mapping.
• تأكد من Response المطلوب.
• حدد Retry Strategy.
• فعّل Logging أو وسيلة مناسبة لمتابعة الأخطاء.
• فكر في Duplicate Events.
• اختبر سيناريو النجاح.
• اختبر سيناريو الفشل.
• اختبر Endpoint غير المتاح.
• اختبر البيانات الناقصة أو غير المتوقعة.
• راقب التكامل بعد تشغيله.

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

كيف تعرف أن تصميم التكامل جيد؟

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

اسأل عن دورة الحياة الكاملة:

ماذا يحدث عند نجاح الطلب؟

ماذا يحدث عند فشل السيرفر؟

ماذا يحدث عند وصول Payload ناقص؟

ماذا يحدث عند وصول الحدث مرتين؟

كيف أعرف سبب الخطأ؟

كيف أغير Workflow عندما تتغير احتياجات المشروع؟

كلما كانت الإجابات واضحة، كان تصميم التكامل أقرب إلى Production Architecture حقيقية.

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

شرح WhatsApp API وWebhook

أتمتة WhatsApp وربطه مع CRM

ربط Shopify مع WhatsApp

أتمتة WooCommerce مع WhatsApp

n8n وWhatsApp Automation

تكامل WhatsApp API مع الأنظمة

الأسئلة الشائعة حول Webhook وWhats360

ما هو Webhook؟

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

ما الفرق بين Incoming وOutgoing Webhook؟

Incoming يعني أن البيانات تأتي من نظام خارجي إلى Whats360. أما Outgoing فيعني أن Whats360 يرسل بيانات أو أحداثًا إلى نظام خارجي.

هل Webhook بديل عن API؟

ليس بالضرورة. Webhook مناسب لنقل الأحداث، بينما API يستخدم لتنفيذ عمليات أو طلب بيانات برمجيًا. وفي كثير من المشاريع يمكن استخدام الاثنين معًا.

هل يمكن استخدام Webhook مع Shopify؟

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

هل يمكن ربط WooCommerce مع WhatsApp باستخدام Webhook؟

يمكن بناء تدفق يرسل أحداث WooCommerce إلى Endpoint استقبال ثم يستخدم البيانات لبناء إجراء مناسب داخل طبقة WhatsApp.

هل يمكن استخدام Webhook مع n8n؟

نعم، يمكن استخدام Webhook كـTrigger داخل Workflow في n8n لاستقبال الأحداث ثم تنفيذ إجراءات متعددة بناءً على البيانات المستلمة.

لماذا نحتاج إلى JSON في Webhook؟

JSON تنسيق شائع ومنظم لتبادل البيانات بين الأنظمة، ويسمح بتمرير حقول متعددة يمكن للنظام المستلم قراءتها ومعالجتها.

ما أهمية Secret؟

Secret يساعد في إضافة طبقة تحقق من مصدر الطلب، بحيث لا يتم التعامل مع الطلبات الواردة باعتبارها موثوقة لمجرد وصولها إلى Endpoint.

ماذا يحدث إذا فشل Webhook؟

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

لماذا يجب الاهتمام بتكرار Webhook؟

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

هل Webhook مناسب للأتمتة؟

نعم، Webhook مناسب جدًا كبداية لـWorkflow يعتمد على وقوع حدث. ويمكن دمجه مع منصات الأتمتة مثل n8n أو Make أو Zapier لبناء سيناريوهات متعددة الخطوات.

متى أحتاج إلى Webhook ومتى أحتاج إلى API؟

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

الخلاصة

الـWebhook يصبح أكثر قيمة عندما تتوقف عن النظر إليه باعتباره مجرد URL، وتبدأ في التعامل معه باعتباره طبقة Events تربط الأنظمة ببعضها.

يمكن أن يبدأ الحدث داخل متجر إلكتروني وينتهي برسالة WhatsApp، أو يبدأ برسالة من العميل وينتهي بتحديث داخل CRM.

وقد يكون المسار بسيطًا:

Shopify → Webhook → Whats360 → WhatsApp

وقد يكون أكثر تعقيدًا:

WhatsApp → Whats360 → Webhook → n8n → CRM → Automation

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

وعندما يتم تصميم هذه الطبقات بشكل صحيح، يصبح WhatsApp جزءًا من منظومة العمل بدل أن يكون قناة منفصلة تعتمد على التدخل اليدوي في كل عملية.

وهنا تظهر قيمة Whats360: ليس باعتباره مجرد أداة لإرسال الرسائل، وإنما كطبقة يمكن أن تدخل داخل Architecture أكبر تربط WhatsApp بالمتاجر وCRM وأدوات الأتمتة والأنظمة البرمجية.

إذا كنت مطورًا، ابدأ من الـEvent والـPayload والـEndpoint. وإذا كنت صاحب متجر أو نشاط تجاري، ابدأ من العملية التي تريد أتمتتها والنتيجة التي تريد أن يصل إليها العميل. في الحالتين، عندما تكون خريطة البيانات واضحة، يصبح اختيار طريقة التكامل أكثر سهولة، ويصبح بناء Workflow قابل للتوسع أقرب إلى التنفيذ الفعلي.

تواصل لتنفيذ التكامل