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

لكن السؤال الأهم ليس فقط: ما هو Webhook؟ وإنما: من سيرسل البيانات إلى من؟ هل المتجر أو النظام الخارجي سيرسل البيانات إلى Whats360، أم أن Whats360 سترسل أحداث WhatsApp إلى نظامك؟

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

في هذا الدليل سننتقل من فهم الفكرة إلى اختيار البنية المناسبة، ثم تنفيذ Incoming وOutgoing Webhooks، والتعامل مع JSON وField Mapping، وربط أدوات الأتمتة، واختبار Payload، وإضافة طبقة حماية مناسبة.

المبدأ الذي يحل معظم مشاكل Webhook

لا تبدأ من مكان وجود زر Webhook داخل لوحة التحكم. ابدأ من اتجاه البيانات.

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

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

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

أما عندما تحتاج إلى Endpoint مخصص أو منطق برمجي معقد، فقد تحتاج إلى تشغيله على بنية سحابية مناسبة مثل DigitalOcean أو Hetzner Cloud أو خدمات سحابية من AWS.

لماذا لا تبدأ ببناء سيرفر كامل؟

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

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

ما هو HookURL داخل Whats360؟

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

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

ومن داخل لوحة التحكم يكون المسار العملي لإنشاء الرابط هو التوجه إلى HookURL، ثم إنشاء رابط جديد، وتحديد الـInstance، واختيار اسم واضح للاستخدام مثل Shopify Orders، ثم إضافة Secret عند الحاجة، وبعد ذلك نسخ الرابط ووضعه في النظام الخارجي.

تسمية الرابط بطريقة واضحة مهمة عندما يكون لديك أكثر من Workflow. فبدل إنشاء مجموعة روابط يصعب تمييزها، يصبح اسم مثل “Shopify Orders” أو “CRM Incoming” مرتبطًا بالوظيفة التي يؤديها.

ميزة عملية

قلّل التطوير عندما يكون الرابط الجاهز كافيًا

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

استكشف Whats360

متى تحتاج إلى Webhook مخصص وField Mapping؟

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

قد يرسل النظام بيانات بسيطة مثل:

{
  "phone": "+201234567890",
  "message": "تم استلام طلبك بنجاح",
  "name": "محمد"
}

في هذه الحالة تكون البيانات واضحة: رقم الهاتف في phone، والنص في message، والاسم في name.

لكن الأنظمة الأكثر تعقيدًا قد ترسل بنية مختلفة:

{
  "customer": {
    "name": "محمد",
    "phone": "+201234567890"
  },
  "order": {
    "status": "paid"
  }
}

هنا يأتي دور Field Mapping. الفكرة ليست مجرد استقبال JSON، وإنما تحديد المكان الذي توجد فيه البيانات وربطها بالحقل المطلوب.

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

تنفيذ Incoming Webhook في Whats360

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

رابط الاستقبال المخصص

وفق بنية الربط المتاحة، يمكن أن يكون مسار استقبال البيانات:

POST /api/instances/{id}/webhooks/{webhook_id}/incoming

مع تحديد نوع البيانات:

Content-Type: application/json

ثم إرسال البيانات في Body الطلب بصيغة JSON.

{
  "phone": "+201234567890",
  "message": "مرحبًا محمد، تم تأكيد طلبك.",
  "name": "محمد"
}

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

مثال: متجر إلكتروني يرسل رسالة تلقائية

لنفترض أنك تستخدم WooCommerce، وتريد ربط حدث الطلب مع Whats360.

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

وتوفر WooCommerce آلية Webhooks لإرسال أحداث المتجر إلى URL خارجي، مع إعدادات تتعلق بالحدث وعنوان التسليم وSecret. يمكن مراجعة التوثيق الرسمي في WooCommerce Webhooks.

Outgoing Webhook: عندما تصبح Whats360 مصدر الأحداث

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

في هذا السيناريو تضع رابط URL الخاص بسيرفرك أو أداة الأتمتة داخل إعدادات الـOutgoing Webhook، ثم تحدد الأحداث التي تريد إرسالها.

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

• Incoming Message
• Outgoing Message
• Failed Message
• Subscription Expiry

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

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

• phone
• message
• sender_name
• instance_id
• message_id
• chat_jid
• timestamp
• media_url

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

فرصة الأتمتة

حوّل أحداث WhatsApp إلى Triggers داخل أنظمة العمل

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

هذا هو جوهر التكامل: ربط الحدث بالإجراء الذي يجب أن يحدث بعده.

ربط Whats360 مع n8n لبناء Workflow متعدد الخطوات

عندما تكون العملية أكبر من مجرد استقبال البيانات، يمكن أن تعمل n8n كطبقة Automation بين Whats360 والخدمات الأخرى.

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

هذه البنية تقلل الحاجة إلى كتابة Backend كامل لكل خطوة، خصوصًا عندما تكون العمليات عبارة عن سلسلة واضحة من Triggers وActions.

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

كيف تختار بين HookURL وWebhook مخصص وn8n؟

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

يمكن أيضًا استخدام Make أو Zapier عندما يكون المطلوب بناء أتمتة وربط خدمات متعددة دون تطوير Backend كامل. المهم أن يكون اختيار الأداة مبنيًا على الـWorkflow وليس على شهرة الأداة.

وفي حالات التجارة الإلكترونية، يمكن ربط منصات مثل Shopify أو WooCommerce بمسار Webhook مناسب، ثم تمرير البيانات إلى Whats360 أو إلى طبقة Automation بحسب اتجاه البيانات.

طبقة الأمان: احمِ Webhook قبل معالجة البيانات

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

يمكن استخدام وسائل تحقق مناسبة مثل Secret Key أو Headers مخصصة مثل Authorization أو آليات توقيع تعتمد على HMAC عندما يدعمها النظام الخارجي.

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

عند التكامل مع Shopify مثلًا، تستخدم Shopify آلية HMAC للتحقق من Webhooks، وتوثق استخدام رأس X-Shopify-Hmac-Sha256 للتحقق من صحة الطلب قبل معالجته. يمكن الرجوع إلى توثيق Shopify الرسمي للـWebhooks لمراجعة تفاصيل التنفيذ.

سيناريوهات عملية لاستخدام Webhooks مع Whats360

أتمتة الطلبات من المتجر

عندما ينشئ العميل طلبًا جديدًا، يمكن أن ينتقل الحدث من المتجر إلى Whats360، ثم تستخدم البيانات المناسبة لإنشاء رسالة WhatsApp.

إرسال المحادثات إلى CRM

في الاتجاه المعاكس، يمكن أن تصبح الرسالة إلى CRM عبر Outgoing Webhook.

تسجيل البيانات عبر n8n

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

التعامل مع فشل الإرسال

يمكن استخدام حدث Failed Message كـTrigger لإرسال البيانات إلى نظام داخلي أو Workflow مخصص للتعامل مع حالات الفشل.

ماذا تستفيد الشركات من هذه البنية؟

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

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

هذا النوع من التكامل مفيد خصوصًا عندما تكون لديك عمليات متكررة لا تريد تنفيذها يدويًا في كل مرة.

أخطاء شائعة عند إعداد Webhook

اختيار الاتجاه الخاطئ

أكثر الأخطاء وضوحًا هو استخدام Incoming بينما المطلوب فعليًا أن ترسل Whats360 الأحداث إلى نظام خارجي، أو العكس. اسأل دائمًا: من هو مصدر الحدث؟

بناء سيرفر دون حاجة

إذا كان HookURL أو أداة Automation تحقق المطلوب، فقد يكون بناء Backend كامل إضافة غير ضرورية للتعقيد والصيانة.

خطأ في Field Mapping

قد يصل الـPayload بنجاح، لكن إذا كان رقم الهاتف موجودًا مثلًا داخل customer.phone بينما النظام يبحث عن phone فلن تحصل على النتيجة المتوقعة دون Mapping صحيح.

Payload غير صحيح

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

عدم اختبار Webhook

تشغيل التكامل مباشرة على بيئة الإنتاج قبل فحص البيانات قد يجعل اكتشاف المشكلة أصعب. الأفضل اختبار الطلب والـPayload أولًا.

تجاهل الحماية

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

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

في Outgoing Webhook، اختر الأحداث التي يحتاجها الـWorkflow فعلًا. كل Event إضافي يجب أن يكون له سبب واضح داخل النظام المستلم.

فحص قبل الإنتاج

اختبر الـPayload قبل أن تعتمد عليه

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

فحص Webhook

كيف تختبر Webhook قبل تشغيله على النظام الحقيقي؟

الاختبار الجيد يبدأ من أصغر جزء ممكن، ثم ينتقل تدريجيًا إلى Workflow الكامل.

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

متى تحتاج إلى مطور أو System Integrator؟

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

أما عندما يصبح المسار مثل:

فهنا يصبح وجود مطور أو System Integrator أكثر أهمية، خصوصًا عندما تحتاج إلى Authentication مخصصة، أو معالجة Payload معقدة، أو Database خاصة، أو منطق أعمال لا توفره أدوات الأتمتة الجاهزة.

وإذا كان اهتمامك يتجه إلى البرمجة والتكاملات وواجهات API، يمكنك متابعة المحتوى المرتبط بهذه الموضوعات داخل Affiegy.

خريطة اختيار الحل المناسب

بدل حفظ أسماء الأدوات، استخدم الأسئلة التالية لاتخاذ القرار:

• هل النظام الخارجي سيرسل البيانات إلى Whats360؟ استخدم Incoming Webhook أو HookURL.
• هل Whats360 سترسل أحداث WhatsApp إلى نظامك؟ استخدم Outgoing Webhook.
• هل تحتاج إلى تحويل بنية البيانات؟ استخدم Field Mapping أو طبقة Automation.
• هل لديك عدة خطوات بعد وصول الحدث؟ استخدم n8n أو Make.
• هل تحتاج إلى منطق برمجي خاص؟ استخدم Custom Endpoint.
• هل تريد فحص البيانات قبل الإنتاج؟ استخدم أداة اختبار مثل Webhook.site.

ما علاقة Webhooks بالتجارة الإلكترونية؟

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

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

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

متى يكون HookURL هو الاختيار الأفضل؟

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

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

متى تكون أداة Automation أفضل؟

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

مثلًا:

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

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

متى يكون Custom Server هو الحل الأفضل؟

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

في هذه الحالة يمكن تشغيل Endpoint على بنية سحابية مثل DigitalOcean أو Hetzner Cloud أو AWS وفق احتياجات المشروع.

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

حوّل التكامل من فكرة إلى Workflow

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

وإذا كان مشروعك يحتاج إلى ربط WhatsApp بالمتجر أو CRM أو نظام مخصص، يمكنك البدء من Whats360 ثم بناء الـWorkflow المناسب حول احتياجك الفعلي.

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

ابدأ من المشكلة وليس من الأداة

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

إذا كانت العملية مباشرة، استخدم HookURL. إذا كانت البيانات تحتاج إلى تحويل، استخدم Field Mapping. إذا كانت هناك عدة خطوات، استخدم n8n أو Make. وإذا كان لديك منطق خاص، انتقل إلى Endpoint مخصص.

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

هل لديك Workflow تريد ربطه عبر WhatsApp؟

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

استكشف Whats360

الخلاصة

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

عندما يكون النظام الخارجي هو مصدر البيانات، يكون Incoming Webhook هو الاتجاه الطبيعي. وعندما تكون Whats360 هي مصدر أحداث WhatsApp، يكون Outgoing Webhook هو الاتجاه المناسب.

بعد تحديد الاتجاه، يأتي اختيار طبقة التنفيذ: HookURL للربط المباشر، Field Mapping عندما تحتاج إلى ربط بنية البيانات، n8n أو Make عندما تحتاج إلى Workflow متعدد الخطوات، وCustom Server عندما تحتاج إلى منطق برمجي خاص.

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

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

الكلمات المفتاحية

Webhooks في Whats360، Whats360 Webhook، WhatsApp Webhook، Incoming Webhook، Outgoing Webhook، HookURL، Field Mapping، WhatsApp API، WhatsApp Automation، Webhook API، JSON Webhook، CRM Integration، n8n WhatsApp، WhatsApp CRM، ربط WhatsApp بالمتجر، ربط WhatsApp مع CRM، أتمتة WhatsApp، Webhook للمتاجر الإلكترونية، API Integration، System Integration، WhatsApp Notifications، Webhook Automation.

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

• ما الفرق بين Incoming وOutgoing Webhook؟
• ما هو HookURL في Whats360؟
• هل أحتاج إلى سيرفر لاستخدام Webhook؟
• كيف أستخدم Field Mapping مع JSON؟
• كيف أربط Whats360 مع n8n؟
• كيف أربط Whats360 مع متجر إلكتروني؟
• ما البيانات التي يرسلها Outgoing Webhook؟
• ما الفرق بين Webhook وAPI؟
• كيف أحمي Webhook باستخدام Secret أو Headers؟
• كيف أختبر Webhook قبل تشغيله في الإنتاج؟
• متى أحتاج إلى Custom Server؟
• متى أحتاج إلى مطور أو System Integrator؟
• كيف أتعامل مع Failed Message Event؟
• كيف أربط WhatsApp بالـCRM باستخدام Webhook؟
• كيف أحول حدثًا من المتجر إلى رسالة WhatsApp تلقائية؟

محتوى مرتبط

لمتابعة موضوعات مرتبطة بالتقنية والأتمتة والتجارة الإلكترونية، يمكنك استكشاف:
الأتمتة،
البرمجة والتكاملات وواجهات API،
التجارة الإلكترونية،
CRM،
والتسويق عبر واتساب.