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

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

وهنا تظهر أهمية Webhooks؛ لأنها تسمح بتحويل الأحداث التي تحدث داخل نظام إلى بيانات تنتقل تلقائيًا إلى نظام آخر، أو استقبال أحداث من متجر أو تطبيق خارجي وتحويلها إلى إجراء على WhatsApp.

في Whats360 يمكن تصور التكامل عبر Webhook في اتجاهين رئيسيين: بيانات تخرج من WhatsApp إلى نظام خارجي، وبيانات تدخل إلى Whats360 من متجر أو تطبيق أو نظام آخر ليتم استخدامها في تشغيل رسالة WhatsApp.

ما هو Webhook ولماذا تحتاج إليه الأنظمة الحديثة؟

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

لنفترض أن لديك متجرًا إلكترونيًا وتريد معرفة متى يتم إنشاء طلب جديد. الطريقة التقليدية القائمة على Polling قد تجعل نظامك يسأل المتجر بصورة متكررة:

هل يوجد طلب جديد؟
لا

هل يوجد طلب جديد؟
لا

هل يوجد طلب جديد؟
نعم

اجلب بيانات الطلب

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

تم إنشاء الطلب
↓
إرسال Webhook
↓
Endpoint
↓
معالجة البيانات
↓
تنفيذ الإجراء المطلوب

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

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

كيف تعمل Webhooks داخل Whats360؟

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

في الاتجاه الأول، يكون الحدث داخل WhatsApp.

عميل يرسل رسالة
↓
WhatsApp
↓
Whats360
↓
Outgoing Webhook
↓
CRM / Server / Automation

في الاتجاه الثاني، يكون الحدث خارج WhatsApp.

عميل ينشئ طلبًا
↓
المتجر الإلكتروني
↓
Incoming Webhook
↓
Whats360
↓
WhatsApp
↓
العميل

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

Incoming Webhook وOutgoing Webhook: ما الفرق؟

بدلًا من حفظ المصطلحين بشكل منفصل، اسأل نفسك سؤالًا بسيطًا:

أين حدث الحدث الذي أريد التعامل معه؟

إذا حدث داخل WhatsApp، ثم أردت إرسال البيانات إلى نظام خارجي، فالاتجاه هو Outgoing.

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

السيناريو	الاتجاه
رسالة وصلت إلى WhatsApp وتريد تسجيلها في CRM	Outgoing Webhook
رسالة وصلت وتريد تشغيل Workflow خارجي	Outgoing Webhook
إنشاء طلب في المتجر وتريد إرسال إشعار للعميل	Incoming Webhook
تحديث حالة طلب وتريد إرسال WhatsApp	Incoming Webhook
إرسال أحداث WhatsApp إلى سيرفر مخصص	Outgoing Webhook
إرسال بيانات من نظام خارجي إلى Whats360	Incoming Webhook

ربط WhatsApp بالـCRM باستخدام Outgoing Webhook

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

Customer
↓
WhatsApp
↓
Whats360
↓
Outgoing Webhook
↓
CRM Endpoint
↓
Database

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

وقد تشمل العملية:

• استخراج رقم الهاتف.
• قراءة محتوى الرسالة.
• تحديد اسم المرسل.
• تحديد الـInstance المرتبط بالحدث.
• تسجيل وقت الرسالة.
• حفظ معرف الرسالة.
• معالجة الوسائط عند وجودها.
• تشغيل Workflow إضافي داخل النظام.

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

ما البيانات التي يمكن أن يحتوي عليها Payload؟

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

ومن المتغيرات المتاحة في البيانات الصادرة من Webhook:

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

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

فمثلًا يمكن للنظام الخارجي استخدام phone للعثور على العميل، ثم استخدام message لإضافة الرسالة إلى سجل المحادثة.

إرسال بيانات متجر إلكتروني إلى Whats360

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

Order Created
↓
Shopify / WooCommerce
↓
Webhook
↓
Whats360
↓
قراءة بيانات العميل
↓
بناء الرسالة
↓
WhatsApp

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

ربط Shopify بـWhats360 عبر Webhook

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

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

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

وبذلك يمكن أن يصبح المسار:

إنشاء الطلب
↓
Shopify Webhook
↓
Whats360
↓
قراءة رقم الهاتف
↓
قراءة اسم العميل
↓
قراءة رقم الطلب
↓
إرسال رسالة WhatsApp

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

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

ويستطيع النظام استخراج البيانات المطلوبة من البنية الداخلية للـJSON، مثل اسم العميل ورقم الهاتف ورقم الطلب.

التحقق من Webhooks القادمة من Shopify

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

يعتمد Shopify على آلية HMAC مرتبطة بـHeader مخصص يمكن استخدامه للتحقق من سلامة الطلب ومصدره. ويمكن استخدام Secret ضمن تصميم التكامل بحيث لا يتم التعامل مع أي بيانات واردة على أنها موثوقة تلقائيًا.

الفكرة الأساسية هي:

Webhook Request
↓
التحقق من المصدر
↓
التحقق من التوقيع عند استخدامه
↓
التحقق من Payload
↓
معالجة البيانات

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

ربط WooCommerce بـWhats360

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

يمكن أن تشمل الإعدادات:

• اسم Webhook.
• الحالة Active.
• الحدث أو Topic المطلوب.
• Delivery URL.
• Secret.

ثم يصبح النظام قادرًا على التعامل مع أحداث المتجر وفق الـWorkflow الذي تم تصميمه.

WooCommerce
↓
Order Event
↓
Webhook
↓
Whats360 Endpoint
↓
تحليل البيانات
↓
WhatsApp

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

استخدام n8n لبناء Workflows أكثر تعقيدًا

عندما تكون العملية بسيطة، قد يكفي الربط المباشر بين النظام وWhats360. لكن عندما تريد إدخال عدة خدمات وقواعد وشروط، يمكن استخدام n8n كطبقة Automation.

مثلًا:

WhatsApp Message
↓
Whats360
↓
n8n Webhook Trigger
↓
تحليل الرسالة
↓
تحديد نوع العميل
↓
CRM
↓
تنفيذ الإجراء
↓
إرسال النتيجة

يمكن أن يصبح الـWebhook مجرد بداية لسلسلة Workflow كاملة.

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

وهذا يجعل Webhook جزءًا من بنية أتمتة وليس مجرد قناة لنقل البيانات.

صفحة Webhooks في Whats360 وما الذي تتحكم فيه؟

عند إعداد Webhook داخل Whats360، توجد مجموعة من العناصر التي تساعد في تحديد طريقة عمل الاتصال.

اسم Webhook

الاسم يستخدم لتمييز Webhook داخل لوحة التحكم. ومن الأفضل أن يكون الاسم واضحًا ويعبر عن الوظيفة، مثل:

CRM Incoming Messages

أو:

Shopify Order Notifications

الهدف هو أن تعرف وظيفة Webhook بمجرد رؤيته داخل قائمة الإعدادات.

نوع الاتصال

هنا يتم تحديد اتجاه البيانات؛ هل Webhook مخصص لإرسال الأحداث إلى نظام خارجي، أم لاستقبال بيانات من نظام خارجي؟

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

رابط URL

في حالة Outgoing، يكون الرابط هو Endpoint الخارجي الذي ستستقبل عليه البيانات.

أما في حالة Incoming، فيكون الرابط هو Endpoint الذي يستقبل البيانات القادمة من المتجر أو التطبيق.

Secret

يمكن استخدام Secret كجزء من آلية التحقق من الطلبات. وجود طبقة تحقق يساعد على منع التعامل مع طلبات غير موثوقة عند تصميم التكامل بطريقة تعتمد على المفتاح السري.

Triggers

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

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

إعادة المحاولة Retry Mechanism ولماذا تحتاج إليها؟

الإنترنت والأنظمة البرمجية ليست متاحة بصورة مثالية طوال الوقت. قد يكون السيرفر الخارجي متوقفًا مؤقتًا أو قد يحدث Timeout أو خطأ HTTP.

لذلك تتضمن إعدادات Webhook آلية لإعادة المحاولة عند فشل التسليم.

يمكن أن تشمل الإعدادات:

• عدد المحاولات.
• التأخير بين المحاولات.

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

والهدف من Retry هو زيادة احتمالية وصول الحدث في حالة وجود مشكلة مؤقتة.

لكن هناك جانبًا آخر يجب أن يضعه المطور في الحسبان:

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

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

لذلك من الأفضل تصميم المعالجة بحيث تستطيع اكتشاف الأحداث المكررة عندما يكون التكرار مؤثرًا في النتيجة.

Field Mapping: عندما لا تكون بيانات النظام الخارجي موحدة

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

قد تكون البيانات مثل:

{
  "customer": {
    "phone": "+201234567890"
  }
}

بينما قد يرسل نظام آخر:

{
  "mobile_number": "+201234567890"
}

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

{
  "user": {
    "contact": {
      "number": "+201234567890"
    }
  }
}

المعلومة الأساسية واحدة، لكن مسارها داخل JSON مختلف.

هنا تأتي أهمية Field Mapping، حيث يمكن تحديد المسار الذي يحتوي على رقم الهاتف وربطه بالحقل المطلوب داخل Webhook.

ويمكن تطبيق الفكرة على:

• phone
• message
• name

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

إرسال طلب POST إلى Webhook

عندما يريد نظام خارجي إرسال بيانات إلى Endpoint مخصص لتشغيل رسالة WhatsApp، يمكن أن يكون الطلب بصيغة POST وبمحتوى JSON.

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

{
  "phone": "+201234567890",
  "message": "Your order #1234 is confirmed!",
  "name": "Ahmed"
}

الفكرة هنا أن النظام الخارجي يرسل الحقول التي يحتاجها Webhook، مثل رقم الهاتف والرسالة واسم العميل.

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

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

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

كيف تستخدم المتغيرات الديناميكية داخل رسالة WhatsApp؟

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

يمكن استخدام المتغيرات الديناميكية المتاحة في البيانات المستقبلة لبناء نص يعتمد على الحقول التي تم تحديدها في Mapping.

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

مرحبًا {{name_field}}

تم تأكيد طلبك رقم {{order_field}}.

شكرًا لاستخدامك متجرنا.

وهنا يتم استبدال المتغيرات بالقيم القادمة من الطلب.

النتيجة أن رسالة واحدة يمكن أن تعمل مع عدد كبير من العملاء، بينما تختلف بيانات كل رسالة حسب الـPayload.

كيف تتعامل مع أخطاء Webhook؟

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

هل حدث Event؟
↓
هل تم إنشاء Request؟
↓
هل تم إرسال Request؟
↓
هل وصل إلى Endpoint؟
↓
هل Payload صحيح؟
↓
هل تم قبول الطلب؟
↓
هل تمت معالجة البيانات؟
↓
هل تم تنفيذ الإجراء؟
↓
هل وصلت رسالة WhatsApp؟

هذا الأسلوب يحول مشكلة كبيرة مثل “الـWebhook لا يعمل” إلى سلسلة من الأسئلة الصغيرة التي يمكن اختبار كل واحدة منها.

العرض	ما الذي يمكن فحصه؟
لا تصل البيانات	URL وEndpoint والاتصال
البيانات تصل لكن الحقول فارغة	Payload وField Mapping
الطلب يتكرر	Retry والاستجابة
الطلب مرفوض	Secret أو آلية التحقق
الـWorkflow لا يعمل	Trigger والشروط داخل النظام
الرسالة لا ترسل	رقم الهاتف والبيانات المطلوبة

مشكلة تكرار الأحداث وكيف تمنع آثارها

من الأخطاء التي قد تظهر في أي بنية تعتمد على Webhooks التعامل مع التكرار وكأنه مستحيل.

قد يرسل النظام الحدث، ثم تحدث مشكلة في الاستجابة، فيعيد الإرسال. إذا كان النظام المستقبل ينفذ العملية مباشرة في كل مرة، فقد يؤدي ذلك إلى نتائج مكررة.

مثلًا:

Order Created
↓
Webhook
↓
إرسال رسالة
↓
مشكلة في الاستجابة
↓
Retry
↓
إرسال الرسالة مرة أخرى

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

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

الأمان في Webhooks: لا تجعل Endpoint نقطة ضعف

أي Endpoint متاح عبر الإنترنت يحتاج إلى التعامل معه باعتباره نقطة اتصال حساسة.

من الممارسات الأساسية:

• استخدام HTTPS.
• حماية Secrets.
• التحقق من التوقيع عند توفر آلية Signature أو HMAC.
• فحص بنية Payload.
• رفض البيانات غير المتوقعة.
• عدم وضع المفاتيح السرية داخل مستودعات عامة.
• تسجيل الأخطاء والطلبات بطريقة تساعد على التشخيص.

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

Webhook أم API أم منصة Automation؟

قد يحدث أحيانًا خلط بين Webhook وAPI وAutomation Platform، رغم أن لكل واحدة وظيفة مختلفة.

متى تستخدم Webhook؟

استخدم Webhook عندما تريد أن يخبرك نظام ما بوقوع حدث.

حدث جديد
↓
إرسال Event
↓
النظام المستقبل

مثال ذلك: إنشاء طلب أو وصول رسالة.

متى تحتاج API؟

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

نظامك
↓
API Request
↓
الخدمة
↓
API Response

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

متى تستخدم Automation Platform؟

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

Webhook
↓
n8n
↓
Condition
↓
CRM
↓
Database
↓
Not
ification

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

متى تستخدم Automation Platform؟

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

Webhook
↓
n8n
↓
Condition
↓
CRM
↓
Database
↓
Notification

متى تحتاج Backend مخصصًا؟

عندما يصبح منطق العمل أكثر تعقيدًا، مثل وجود قواعد أعمال كثيرة أو Database أو Queue أو Authentication أو معالجة مخصصة، يمكن أن يكون Backend خاص هو الخيار الأنسب.

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

تصميم بنية Webhook قابلة للتوسع

في المشروع الصغير قد يكون من السهل أن يقوم Endpoint باستقبال الطلب ثم تنفيذ كل شيء مباشرة.

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

Whats360
↓
Webhook Endpoint
↓
Validation
↓
Queue
↓
Processor
↓
Business Logic
├── CRM
├── Database
├── Notifications
└── Analytics

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

هذا التصميم يصبح مفيدًا عندما يؤدي الحدث الواحد إلى عدة عمليات، مثل تحديث CRM وتسجيل Analytics وإرسال إشعار وتشغيل منطق إضافي.

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

مثال متكامل: من إنشاء الطلب إلى رسالة WhatsApp

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

يمكن بناء الـWorkflow بهذا الشكل:

Order Created
↓
Shopify / WooCommerce
↓
Webhook
↓
Whats360
↓
Field Mapping
↓
Phone + Name + Order
↓
Message Template
↓
WhatsApp
↓
Customer

ويصل Payload مثل:

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

يمكن استخراج:

name = customer.first_name
phone = customer.phone
order = order_number
price = total_price

ثم استخدام هذه البيانات داخل رسالة مخصصة:

مرحبًا {{name}}

تم استلام طلبك رقم {{order}} بنجاح.

قيمة الطلب: {{price}} جنيه.

بهذا يتحول إنشاء الطلب من مجرد حدث داخل المتجر إلى Workflow اتصال كامل مع العميل.

مثال آخر: WhatsApp إلى CRM ثم Automation

يمكن عكس الاتجاه تمامًا عندما تكون الرسالة هي نقطة البداية.

Customer Message
↓
WhatsApp
↓
Whats360
↓
Outgoing Webhook
↓
n8n
↓
CRM
↓
تحليل العميل
↓
Workflow مناسب

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

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

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

Webhook مناسب عندما يكون لديك حدث واضح تريد أن يؤدي إلى إجراء تلقائي.

من الأمثلة:

• إنشاء طلب.
• تحديث حالة الطلب.
• إتمام الدفع.
• إنشاء عميل.
• وصول رسالة WhatsApp.
• إرسال رسالة.
• فشل الإرسال.
• تشغيل Workflow خارجي.
• حفظ المحادثات في CRM.
• إرسال تنبيهات فورية.

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

Webhooks كطبقة ربط بين الأنظمة

عند النظر إلى الصورة الكاملة، يمكن وضع Whats360 داخل منظومة أكبر من الأنظمة:

                 WhatsApp
                    ↕
                 Whats360
                    ↕
                 Webhooks
                    ↕
        ┌───────────┼───────────┐
        ↓           ↓           ↓
       CRM        Store        n8n
        ↓           ↓           ↓
    Database      Orders     Automation

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

الرسالة يمكن أن تحدث تغييرًا في CRM.

والطلب يمكن أن يؤدي إلى رسالة.

وتحديث حالة الطلب يمكن أن يشغل Workflow.

وحدث معين يمكن أن ينتقل إلى قاعدة البيانات أو نظام الإشعارات.

وهذا هو جوهر Webhooks: تحويل الأحداث بين الأنظمة إلى عمليات قابلة للأتمتة.

كيف تبدأ تنفيذ التكامل عمليًا؟

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

مثلًا:

عندما ينشئ العميل طلبًا، أريد إرسال رسالة WhatsApp تلقائية إليه.

ثم حولها إلى Workflow:

Order Created
↓
Webhook
↓
Whats360
↓
Phone Mapping
↓
Message
↓
WhatsApp

أو:

عندما يرسل العميل رسالة، أريد تسجيلها في CRM وتشغيل Workflow.

WhatsApp Message
↓
Whats360
↓
Outgoing Webhook
↓
CRM / Automation

بعد ذلك حدد الحقول المطلوبة، مثل:

• رقم الهاتف.
• اسم العميل.
• الرسالة.
• رقم الطلب.
• حالة الطلب.
• معرف الحدث.

ثم حدد طريقة التحقق من الطلبات، وطريقة التعامل مع الفشل والتكرار.

بهذا يكون لديك تصميم واضح قبل كتابة الكود أو تعديل الإعدادات.

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

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

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

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

Incoming Webhook يستقبل البيانات القادمة من نظام خارجي مثل متجر إلكتروني لاستخدامها في تشغيل WhatsApp. أما Outgoing Webhook فيرسل أحداث وبيانات WhatsApp إلى Endpoint خارجي مثل CRM أو سيرفر مخصص.

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

نعم، يمكن استخدام Outgoing Webhook لإرسال أحداث وبيانات WhatsApp إلى Endpoint تابع للـCRM أو للسيرفر الوسيط الذي يتولى معالجة البيانات وتخزينها.

هل يمكن ربط Webhooks مع متجر إلكتروني؟

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

هل Webhook هو نفسه API؟

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

لماذا قد تصل بيانات Webhook ولكن لا يتم إرسال الرسالة؟

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

ما أهمية Field Mapping؟

Field Mapping يسمح بتحديد مكان البيانات داخل JSON القادم من النظام الخارجي وربطها بالحقول التي يحتاجها Webhook، مثل رقم الهاتف والاسم والرسالة.

ماذا يحدث إذا توقف السيرفر الذي يستقبل Webhook؟

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

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

نعم، يمكن استخدام Webhook كـTrigger داخل n8n لبناء Workflows تربط WhatsApp بخدمات وأنظمة أخرى.

هل Webhook مناسب لكل أنواع التكاملات؟

لا. Webhook مناسب للأحداث التي تريد نقلها فور وقوعها. أما العمليات التي تحتاج إلى استعلامات أو تنفيذ أوامر عند الطلب فقد تحتاج إلى API، بينما قد تحتاج الـWorkflows المعقدة إلى منصة Automation أو Backend مخصص.

كيف أعرف هل أحتاج Incoming أم Outgoing؟

حدد مكان بداية الحدث. إذا بدأ داخل WhatsApp وأردت إخراج البيانات إلى نظامك، استخدم Outgoing. وإذا بدأ في متجر أو تطبيق خارجي وأردت تشغيل WhatsApp، استخدم Incoming.

الخلاصة: Webhook ليس مجرد URL

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

إذا بدأ الحدث داخل WhatsApp وتريد إرساله إلى CRM أو Backend أو منصة Automation، يكون المسار:

WhatsApp
↓
Whats360
↓
Outgoing Webhook
↓
Your System

أما إذا بدأ الحدث داخل المتجر أو التطبيق الخارجي وتريد تشغيل WhatsApp، فيكون المسار:

Your System
↓
Incoming Webhook
↓
Whats360
↓
WhatsApp

بعد تحديد الاتجاه، تأتي بقية طبقات التصميم:

Event
↓
Webhook Direction
↓
Payload
↓
Field Mapping
↓
Security
↓
Validation
↓
Retry
↓
Processing
↓
Business Logic
↓
WhatsApp / CRM / Automation

وعندما يكون التكامل بسيطًا يمكن الاكتفاء بربط مباشر، بينما يمكن إدخال n8n عندما تحتاج إلى Workflow متعدد المراحل، أو Backend مخصص عندما يصبح منطق الأعمال أكثر تعقيدًا.

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