Webhook في Whats360: كيف تربط WhatsApp بالمتاجر وCRM والأنظمة وتحوّل الأحداث إلى أتمتة

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

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

وتعتمد فلسفة Webhook في Whats360 على الروابط الخارجية؛ أي أن الرابط الذي يتم التعامل معه هو Endpoint خارجي تحدده أنت حسب النظام الذي تريد الربط معه. لذلك يمكن أن يكون هذا الرابط تابعًا لمتجر إلكتروني، أو سيرفر خاص، أو نظام CRM، أو أداة أتمتة مثل n8n، أو أي تطبيق قادر على استقبال HTTP Requests.

ما هو Webhook في Whats360؟

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

وهنا يجب التفريق بين اتجاهين أساسيين للعمل. الاتجاه الأول هو إرسال البيانات من Whats360 إلى نظام خارجي، والاتجاه الآخر هو استقبال البيانات من نظام خارجي ليتم استخدامها في تنفيذ إجراء داخل Whats360.

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

كيف تعمل روابط Webhook داخل Whats360؟

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

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

حدث → Webhook → Payload → النظام المستهدف → معالجة البيانات → إجراء تلقائي

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

حدث في المتجر أو النظام → رابط استقبال Whats360 → معالجة البيانات → رسالة WhatsApp أو إجراء داخل المنصة

هذه الطريقة تجعل Webhook جزءًا من Workflow أكبر، وليس مجرد وسيلة لإرسال JSON من مكان إلى آخر.

إرسال البيانات واستقبال البيانات: ما الفرق؟

إرسال البيانات من Whats360 إلى نظام خارجي

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

مثلاً، عندما يستقبل حساب WhatsApp رسالة جديدة، يمكن إرسال معلومات الرسالة إلى Endpoint خارجي. ويمكن للنظام المستلم بعد ذلك حفظ المحادثة في CRM أو تشغيل Workflow أو إرسال إشعار لفريق العمل.

هذا الاتجاه مناسب للمطورين وSystem Integrators الذين يريدون جعل WhatsApp مصدرًا للأحداث داخل أنظمة أخرى.

استقبال البيانات من نظام خارجي إلى Whats360

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

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

العملية	مصدر الحدث	الوجهة	الاستخدام
إرسال البيانات	Whats360	نظام خارجي	CRM، أتمتة، قاعدة بيانات
استقبال البيانات	متجر أو نظام خارجي	Whats360	إرسال رسائل WhatsApp

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

الـAPI والـWebhook ليسا الشيء نفسه، رغم أنهما يعملان معًا في كثير من عمليات التكامل.

في الاستخدام المعتاد للـAPI، يقوم نظام بطلب بيانات أو تنفيذ عملية من نظام آخر. أما Webhook فيعتمد على الأحداث؛ فعندما يقع حدث معين، يتم دفع البيانات تلقائيًا إلى Endpoint محدد.

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

العنصر	API	Webhook
طريقة العمل	طلب واستجابة	حدث وإشعار
بداية العملية	النظام الطالب	الحدث
الاستخدام	تنفيذ عمليات وطلب بيانات	الإبلاغ عن الأحداث
مثال	طلب بيانات عميل	إبلاغ CRM بوصول رسالة

واجهة إدارة Webhook في Whats360

تضم واجهة إدارة Webhook مجموعة من العناصر التي تساعد على إنشاء الروابط وإدارتها ومتابعة القوالب الجاهزة. وتبدأ العملية من قائمة Webhooks التي تعرض الروابط التي تم إنشاؤها سابقًا، مع إمكانية إنشاء Webhook جديد أو استخدام أحد القوالب المتاحة.

قائمة Webhooks النشطة

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

قسم القوالب الجاهزة

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

إنشاء Webhook جديد وإعداداته

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

اسم Webhook

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

نوع العملية

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

رابط Webhook

الرابط هو Endpoint الذي ستصل إليه البيانات أو الذي ستستقبل المنصة من خلاله البيانات حسب نوع العملية. يجب أن يكون الرابط قادرًا على التعامل مع HTTP Requests بالصيغة المتوقعة.

Secret Key

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

اختيار الأحداث

يمكن تحديد Event Topics التي ستؤدي إلى تشغيل Webhook. وتشمل الأحداث المتاحة رسالة واردة، رسالة مرسلة، فشل إرسال، وانتهاء الاشتراك.

• Incoming Message: يتفاعل مع وصول رسالة جديدة.
• Sent Message: يتفاعل مع الرسائل التي تم إرسالها.
• Failed Delivery: يتفاعل مع حالات فشل إرسال الرسالة.
• Subscription Expired: يتعامل مع حدث انتهاء الاشتراك.

إعادة المحاولة Retry Logic

عند فشل إرسال البيانات يمكن استخدام إعدادات إعادة المحاولة. تسمح الإعدادات بتحديد عدد المحاولات من 1 إلى 5، مع قيمة افتراضية تبلغ 3 محاولات، وتحديد التأخير بين المحاولات بالثواني، مع قيمة افتراضية تبلغ 30 ثانية.

وجود Retry Logic مهم لأن فشل الاتصال لا يعني دائمًا أن التكامل غير صالح. فقد يكون السيرفر المستهدف متوقفًا مؤقتًا أو قد يحدث خطأ شبكي مؤقت. إعادة المحاولة تمنح Endpoint فرصة أخرى لاستقبال الحدث.

ما البيانات التي يرسلها Webhook؟

يتم تبادل البيانات في صورة JSON، وهي صيغة شائعة وخفيفة لمعالجة البيانات بين الأنظمة.

من المتغيرات التي يمكن أن تظهر في بيانات الأحداث:

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

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

مثال على Webhook Payload

يمكن أن تكون حمولة البيانات في صورة JSON تحتوي على معرف الحدث وبيانات الطلب والعميل:

{
  "id": 820982911546154508,
  "order_number": 1234,
  "total_price": "100.00",
  "customer": {
    "first_name": "Ahmed",
    "phone": "+201234567890"
  }
}

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

تسمح هذه البنية للنظام المستلم بإنشاء Workflow يعتمد على البيانات الفعلية بدلًا من الاعتماد على تدخل بشري.

قوالب Webhook الجاهزة في Whats360

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

Shopify

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

WooCommerce

قالب WooCommerce يتيح ربط المتجر المبني على WordPress بأحداث الطلبات وتشغيل إشعارات WhatsApp تلقائية.

Webhook مخصص

القالب المخصص مناسب عندما لا تكون المنصة المطلوبة ضمن القوالب الجاهزة أو عندما يحتاج المشروع إلى Workflow خاص.

Odoo وWhatsApp

يتضمن النظام قالبًا لإرسال بيانات WhatsApp إلى Odoo، بالإضافة إلى قالب استقبال بيانات من Odoo لاستخدامها في إشعارات الطلبات أو الفواتير أو تحديثات الحالة.

Salla وZid

يمكن استخدام قوالب استقبال بيانات المتاجر لإرسال رسائل WhatsApp عند تأكيد الطلب أو متابعة حالته.

Easy Orders وYouCan

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

Meta Lead Ads

يسمح قالب إعلانات Facebook Lead Ads بتحويل بيانات العميل المحتمل إلى Workflow للتواصل معه عبر WhatsApp بعد ملء نموذج الإعلان.

Google Sheets وGoogle Forms

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

بوابات الدفع

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

Make وZapier

يساعد قالب توجيه أحداث WhatsApp على تمرير الرسائل والميديا والمرفقات بصيغة JSON إلى منصات الأتمتة الخارجية، بحيث تصبح الأحداث مدخلًا لسيناريو Automation أكبر.

Zoho CRM وHubSpot

يمكن استخدام قالب مزامنة المحادثات لتسجيل رسائل ومرفقات العملاء القادمة من WhatsApp داخل ملف العميل في نظام CRM.

توجيه الوسائط والملفات

يمكن إرسال روابط الوسائط الواردة من WhatsApp مع بيانات المرسل إلى وجهة مخصصة، لتصبح الملفات جزءًا من Workflow أو نظام تخزين أو معالجة آخر.

ربط Whats360 مع Shopify

يبدأ التكامل بإنشاء Webhook من نوع استقبال البيانات ثم اختيار قالب Shopify ونسخ رابط الاستقبال. بعد ذلك يتم الدخول إلى إعدادات Shopify والوصول إلى قسم Notifications ثم Webhooks وإنشاء Webhook جديد.

يتم تحديد الحدث المطلوب واختيار JSON كلغة للبيانات ثم وضع رابط الاستقبال في خانة الرابط. بعد الحفظ، تقوم Shopify بإرسال البيانات عند وقوع الحدث المحدد.

أحداث Shopify المهمة

• orders/create: عند إنشاء طلب جديد.
• orders/updated: عند تحديث الطلب.
• orders/paid: عند تسجيل دفع الطلب.
• customers/create: عند إنشاء عميل جديد.

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

{
  "id": 820982911946154508,
  "order_number": 1234,
  "total_price": "199.00",
  "customer": {
    "first_name": "[PERSON_ID]",
    "phone": "[PHONE_ID]"
  }
}

وبالنسبة للتحقق من المصدر، يمكن التعامل مع ترويسة X-Shopify-Hmac-SHA256 للتحقق من أن الطلب صادر من الجهة المتوقعة. كما يمكن استخدام السر عند إنشاء Webhook وفق إعداد التكامل.

ربط Whats360 مع WooCommerce

في WooCommerce يبدأ الإعداد بإنشاء Webhook جديد من نوع استقبال البيانات واختيار قالب WooCommerce ثم نسخ رابط الاستقبال.

بعد ذلك يتم الانتقال في لوحة WordPress إلى WooCommerce ثم Settings ثم Advanced ثم Webhooks، وإنشاء Webhook جديد وتحديد الاسم والموضوع والحالة النشطة، ثم وضع الرابط المنسوخ في خانة Delivery URL.

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

أحداث WooCommerce

• Order created: عند إنشاء طلب جديد.
• Order updated: عند تغيير بيانات أو حالة الطلب.
• Customer created: عند إنشاء عميل.
• Product updated: عند تحديث منتج.

مثال على حمولة WooCommerce:

{
  "id": 727,
  "status": "processing",
  "total": "150.00",
  "billing": {
    "first_name": "[PERSON_ID]",
    "phone": "[PHONE_ID]"
  }
}

وعند حدوث مشكلة في التكامل يمكن مراجعة Delivery Logs من إعدادات WooCommerce. كما يجب التأكد من أن Endpoint يعيد استجابة HTTP 200 بنجاح. الفشل المتكرر قد يؤدي إلى تعطيل Webhook، لذلك تعتبر مراقبة سجلات التوصيل جزءًا مهمًا من عملية التشغيل.

ربط Whats360 مع Odoo وCRM

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

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

هذا النوع من التكامل مناسب بشكل خاص للشركات التي تعتمد على CRM أو ERP وتريد تقليل العمل اليدوي بين فريق المبيعات والنظام وWhatsApp.

ربط Webhook مع n8n

n8n يمكن أن يعمل كطبقة Workflow بين Whats360 وعدد كبير من الخدمات. تبدأ العملية بإنشاء Webhook داخل Whats360 ونسخ رابط الإشعار، ثم إضافة Webhook Trigger داخل n8n ووضع الرابط في المكان المخصص.

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

بعد الانتهاء يتم تفعيل السيناريو واختباره بإرسال رسالة WhatsApp أو تشغيل الحدث المرتبط بالـWebhook.

ميزة هذا التصميم أنه يفصل بين استقبال الحدث وبين منطق العمل. Whats360 يرسل الحدث، بينما يتولى Workflow في n8n تحديد ما يجب أن يحدث بعد ذلك.

ربط Webhook مع Make وZapier

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

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

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

وهنا يصبح Webhook هو Trigger لبقية سلسلة العمليات.

إنشاء Webhook مخصص لإرسال البيانات

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

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

إنشاء رابط استقبال مخصص

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

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

مثال HTTP POST

POST /api/instances/{id}/webhooks/{webhook_id}/incoming
Content-Type: application/json

{
  "phone": "[PHONE_ID]",
  "message": "Your order #1234 is confirmed!",
  "name": "[PERSON_ID]"
}

وعند نجاح الاستقبال يمكن أن تكون الاستجابة:

{
  "status": "success",
  "message": "Webhook received successfully"
}

الفكرة الأساسية هي أن Endpoint يجب أن يستطيع استقبال HTTP POST والتعامل مع JSON وإعادة استجابة صحيحة للنظام المرسل.

روابط الاستقبال الخاصة بالأجهزة

يوفر قسم روابط الاستقبال Webhook URL مخصصًا لكل جهاز لاستقبال الأحداث القادمة من المتاجر والتطبيقات الخارجية مثل Shopify وSalla وZid أو أي تطبيق مخصص.

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

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

كيف تصمم تكامل Webhook قابلًا للاعتماد؟

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

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

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

منع تكرار معالجة الأحداث

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

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

التعامل مع Retry

وجود إعادة المحاولة يعني أن النظام يجب أن يكون قادرًا على استقبال الحدث مرة أخرى دون أن يؤدي ذلك إلى نتائج غير مرغوبة. لذلك يجب أن تكون معالجة الحدث مصممة مع احتمالية التكرار في الاعتبار.

تسجيل الأخطاء

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

ماذا تفعل إذا لم يصل Webhook؟

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

فحص الحدث

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

فحص الرابط

راجع Endpoint وتأكد من أنه صحيح وقابل للوصول، وأنه يستقبل HTTP POST بالصيغة المطلوبة.

فحص الاستجابة

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

فحص السجلات

في WooCommerce يمكن مراجعة سجلات التوصيل. وفي الأنظمة المخصصة يجب الرجوع إلى Logs الخاصة بالسيرفر أو الـWorkflow أو أداة الأتمتة.

فحص Secret Key

إذا كان هناك تحقق من Secret أو Authentication، يجب التأكد من تطابق القيم وطريقة التحقق المستخدمة.

فحص Payload

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

المشكلة	ما الذي تفحصه؟
لا يوجد طلب	الحدث والرابط وإعداد Webhook
طلب يصل ويفشل	HTTP Status وLogs
البيانات تصل ناقصة	Payload وJSON Mapping
الحدث يتكرر	Retry وIdempotency
الطلب مرفوض	Secret وAuthentication

Webhook وAutomation Workflow

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

مثال على Workflow للتجارة الإلكترونية:

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

مثال آخر لخدمة العملاء:

رسالة جديدة → Webhook → CRM → تحديد العميل → تسجيل المحادثة → إشعار فريق المبيعات → متابعة العميل.

أما في نظام الأتمتة فقد يكون المسار:

WhatsApp Event → n8n → معالجة البيانات → Google Sheets → Email → CRM.

بهذه الطريقة يصبح Whats360 جزءًا من منظومة تشغيل أكبر، وليس مجرد واجهة لإرسال الرسائل.

متى تحتاج إلى Middleware؟

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

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

مثلاً يمكن أن يصل حدث واحد من Whats360، ثم يقوم Middleware بإرساله إلى CRM وقاعدة البيانات ونظام الإشعارات في الوقت نفسه، مع الاحتفاظ بسجل للعملية.

استخدام Webhook في إشعارات الطلبات

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

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

استخدام Webhook مع CRM

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

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

استخدام Webhook مع الإشعارات والوسائط

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

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

اختيار بنية Webhook المناسبة

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

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

Checklist قبل تشغيل Webhook في بيئة حقيقية

• تحديد اتجاه البيانات بوضوح.
• اختيار الحدث الصحيح.
• التأكد من صحة Endpoint.
• تحديد صيغة Payload.
• تحديد الحقول المطلوبة.
• اختبار Secret أو Authentication.
• اختبار HTTP Response.
• تفعيل Retry المناسب.
• منع تكرار معالجة الأحداث.
• تفعيل Logs ومراقبة الأخطاء.
• اختبار السيناريو قبل التشغيل الفعلي.
• التأكد من أن النظام المستهدف قادر على التعامل مع البيانات.

أخطاء تصميم Webhook التي يجب تجنبها

الاعتماد على وصول الطلب فقط

وصول HTTP Request لا يعني بالضرورة نجاح العملية بالكامل. يجب أن تكون هناك معالجة واضحة للبيانات واستجابة مناسبة وتسجيل للنتيجة.

عدم التعامل مع التكرار

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

إهمال التحقق من المصدر

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

عدم مراقبة السجلات

بدون Logs يصبح تشخيص المشكلة أصعب، خصوصًا عندما يكون هناك أكثر من نظام بين مصدر الحدث والنتيجة النهائية.

كيف تبني تكامل Webhook قابلًا للتوسع؟

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

بعد نجاح المسار الأساسي يمكن إضافة خطوات أخرى مثل CRM أو Google Sheets أو أدوات الأتمتة أو الإشعارات الداخلية.

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

الفرق بين الرابط والـWorkflow

الرابط وحده لا يمثل الأتمتة. هو نقطة الاتصال التي تنقل الحدث أو تستقبل البيانات. أما Workflow فهو المنطق الذي يحدد ما الذي سيحدث بعد وصول البيانات.

ولهذا يمكن أن يكون Webhook واحد مدخلًا لعدة إجراءات، ويمكن أن يحتوي Workflow واحد على عدة Webhooks ومصادر بيانات حسب طبيعة المشروع.

لماذا يعتبر Webhook مناسبًا للتكامل بين الأنظمة؟

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

عند دمج هذا النموذج مع API وCRM وأدوات Automation يمكن بناء طبقة تشغيل تربط WhatsApp بباقي الأنظمة بطريقة أكثر تنظيمًا.

خلاصة استخدام Webhook في Whats360

Webhook في Whats360 ليس مجرد رابط لإرسال البيانات، بل نقطة اتصال يمكن أن تجعل WhatsApp جزءًا من البنية التشغيلية للمتجر أو الشركة أو النظام البرمجي.

يمكن استخدامه لإرسال أحداث WhatsApp إلى CRM أو أدوات الأتمتة، أو استقبال أحداث المتاجر والأنظمة وتحويلها إلى رسائل WhatsApp، أو بناء تكامل مخصص عبر HTTP POST وJSON، أو استخدام القوالب الجاهزة لتسريع الربط مع Shopify وWooCommerce وOdoo وSalla وZid وn8n وغيرها من السيناريوهات المذكورة.

وتزداد قوة التكامل عندما يتم تصميمه مع التحقق من البيانات، Secret Key، Retry Logic، Idempotency، Logs، والاستجابة الصحيحة من Endpoint. بهذه الطريقة يتحول Webhook من مجرد اتصال بين نظامين إلى طبقة يمكن الاعتماد عليها داخل Workflow متكامل.

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

دليل Whats360 API وربط WhatsApp بالأنظمة

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

ربط Shopify مع WhatsApp باستخدام Webhook

ربط WooCommerce مع WhatsApp باستخدام Webhook

ربط Odoo مع WhatsApp

أتمتة WhatsApp باستخدام n8n

ربط CRM مع WhatsApp

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

الكلمات المفتاحية التي يغطيها المقال

Webhook في Whats360، Whats360 Webhook، Webhook API، WhatsApp API، روابط الاستقبال، إرسال البيانات، استقبال البيانات، Incoming Webhook، Outgoing Webhook، Shopify Webhook، WooCommerce Webhook، Odoo WhatsApp، CRM Integration، n8n WhatsApp، Make WhatsApp، Zapier WhatsApp، تكامل WhatsApp، أتمتة WhatsApp، API Integration، Webhook Payload، JSON Webhook، Retry Logic، Idempotency، Webhook Troubleshooting، تكامل المتاجر، ربط WhatsApp بالأنظمة، WhatsApp Automation، Webhook Integration، REST API، HTTP POST، HTTPS، Middleware، إشعارات الطلبات، إشعارات WhatsApp، ربط Shopify، ربط WooCommerce، ربط Odoo، ربط CRM، Webhook مخصص، روابط Webhook، Webhook URL، Secret Key، Event Topics، Automation Workflow.

الأسئلة التي يجيب عنها المقال

• ما هو Webhook في Whats360؟
• ما الفرق بين Incoming Webhook وOutgoing Webhook؟
• ما الفرق بين Webhook وAPI؟
• كيف يتم إنشاء Webhook في Whats360؟
• ما هي بيانات Webhook Payload في Whats360؟
• كيف أربط Whats360 مع Shopify باستخدام Webhook؟
• كيف أربط Whats360 مع WooCommerce؟
• كيف يمكن ربط Whats360 مع Odoo أو CRM؟
• كيف أستخدم Webhook مع n8n أو Make أو Zapier؟
• كيف أستقبل بيانات Whats360 في Endpoint مخصص؟
• ماذا يحدث إذا فشل إرسال Webhook؟
• ما هو Retry Logic في Webhook؟
• ما هو Idempotency ولماذا يمنع تكرار معالجة الأحداث؟
• كيف أؤمّن Webhook باستخدام Secret Key؟
• كيف أشخّص مشكلة عدم وصول Webhook؟
• متى أستخدم Webhook ومتى أستخدم API؟
• متى أحتاج إلى Middleware في تكامل WhatsApp؟
• كيف أحوّل أحداث WhatsApp إلى Workflow آلي؟
• كيف أستخدم Webhook في إشعارات الطلبات؟
• كيف يمكن إرسال رسائل WhatsApp تلقائيًا عند إنشاء طلب في متجر إلكتروني؟
• كيف أستخدم Webhook في إشعارات الطلبات؟
• كيف يمكن إرسال رسائل WhatsApp تلقائيًا عند إنشاء طلب في متجر إلكتروني؟
• كيف أتعامل مع JSON Payload في تكامل WhatsApp؟
• كيف أمنع تكرار تنفيذ الحدث عند استخدام Retry؟

هل تريد تنفيذ التكامل بدل بنائه يدويًا؟

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