إنشاء Webhook في Whats360: شرح صفحة الإعداد وربط Shopify وWooCommerce برمجيًا
تخيل أن عميلًا أنهى طلبًا من متجرك الإلكتروني. بدل أن يظل الطلب مجرد سجل داخل Shopify أو WooCommerce، يمكن أن يتحول إنشاء الطلب إلى Event، ثم تنتقل بياناته عبر Webhook إلى Whats360، حيث يمكن استخدامها ضمن عملية أتمتة لإرسال إشعار عبر WhatsApp.
هذه هي الفكرة الأساسية وراء Webhook: ربط حدث في نظام بعملية تلقائية في نظام آخر.
وفي منصة Whats360، توفر صفحة «إنشاء ويب هوك جديد» واجهة لإعداد هذا الاتصال، سواء كنت تريد استقبال بيانات من نظام خارجي أو إرسال أحداث من Whats360 إلى سيرفر خارجي.
ما هو Webhook في Whats360؟
الـWebhook هو آلية تعتمد على إرسال البيانات إلى عنوان URL محدد عند حدوث حدث معين.
في التكاملات مع المتاجر الإلكترونية يمكن أن يكون السيناريو مثل:
Customer places order
↓
Shopify / WooCommerce
↓
Webhook Request
↓
Whats360
↓
Processing
↓
WhatsApp Messageوفي الاتجاه العكسي يمكن أن يعمل التكامل هكذا:
Whats360 Event
↓
Webhook
↓
External Server
↓
External Systemلذلك من المهم عدم النظر إلى Webhook باعتباره مجرد رابط URL. هو في الحقيقة نقطة اتصال بين نظامين، تحدد متى تنتقل البيانات، وإلى أين، وما البيانات التي سيتم استخدامها.
ماذا تحتوي صفحة «إنشاء ويب هوك جديد» في Whats360؟
صفحة إنشاء Webhook هي واجهة إعداد التكامل. ومن خلالها يتم تحديد المعلومات التي يحتاجها النظام لتنفيذ عملية الاتصال.
وتشمل الصفحة عددًا من العناصر الأساسية.
اسم Webhook
أول حقل هو اسم الـWebhook.
وظيفته الأساسية هي التعريف بهذا التكامل داخل المنصة، خصوصًا عندما يكون لديك أكثر من Webhook.
من الأفضل استخدام أسماء تصف الوظيفة، مثل:
Shopify New Ordersأو:
WooCommerce Ordersأو:
CRM Notificationsبدل استخدام أسماء عامة لا توضح الغرض من التكامل.
رابط URL الخارجي
هذا الحقل يمثل عنوان نقطة الاتصال الخارجية التي يعتمد عليها التكامل.
وهنا يجب التمييز بين سيناريوهات الاستخدام.
إذا كان النظام الخارجي سيرسل بيانات إلى Whats360، فإنك تحتاج إلى استخدام نقطة الاستقبال المناسبة في عملية التكامل.
أما إذا كان Whats360 سيرسل حدثًا إلى سيرفر خارجي، فإن الـURL يمثل نقطة النهاية التي سيستقبل عليها السيرفر البيانات.
بمعنى آخر، الـURL هو المكان الذي تتحرك إليه البيانات، لكن اتجاه البيانات يعتمد على نوع الـWebhook والسيناريو المستخدم.
إعدادات بريد الإرسال والاستقبال
تتضمن صفحة إنشاء Webhook إعدادات مرتبطة ببريد الإرسال والاستقبال.
وجود هذه الخيارات ضمن إعداد التكامل يسمح بضبط البيانات المتعلقة بالجهة المستخدمة في الإرسال والاستقبال وفق إعدادات الصفحة.
لكن لا ينبغي افتراض وظيفة داخلية إضافية لهذه الحقول غير موثقة في إعدادات المنصة.
Secret
يوجد أيضًا حقل اختياري لإدخال Secret مخصص.
الـSecret عبارة عن قيمة سرية يمكن استخدامها برمجيًا للمساعدة في التحقق من مصدر الطلبات وتأمين الاتصال.
الفكرة الأساسية هي:
Incoming Request
↓
Secret / Verification
↓
Validate Request
↓
Process Payloadولا ينبغي وضع الـSecret في كود مكشوف للعامة أو مشاركته مع أطراف غير موثوقة.
تعامل مع Secret باعتباره معلومة حساسة، واستخدمه ضمن آلية تحقق مناسبة للتكامل.
ما الأحداث التي يمكن تشغيل Webhook عند حدوثها؟
تتيح الصفحة مجموعة من الأحداث التي يمكن ربطها بالـWebhook.
ومن أهمها:
| الحدث | الاستخدام |
|---|---|
| رسالة واردة | تشغيل Workflow عند وصول رسالة |
| فشل إرسال | التعامل مع حالة فشل الإرسال |
| رسالة مرسلة | إرسال معلومات الحدث إلى نظام خارجي |
| انتهاء الاشتراك | مزامنة حالة الاشتراك مع نظام آخر |
الفكرة المهمة هنا أن الـWebhook لا يعمل طوال الوقت بطريقة عشوائية، وإنما يتم تشغيله عندما يحدث Event تم اختياره في الإعدادات.
فمثلًا، إذا كان الهدف هو مزامنة الرسائل الواردة مع نظام CRM خارجي، فإن Event الرسالة الواردة هو الأكثر ارتباطًا بهذا السيناريو.
أما إذا كان الهدف متابعة حالة الاشتراك في نظام خارجي، فيمكن ربط التكامل بحدث انتهاء الاشتراك.
المتغيرات الديناميكية في Webhook
تتضمن الصفحة مجموعة من المتغيرات الديناميكية التي يمكن استخدامها في الرسائل أو عمليات التكامل، ومنها:
{chatid}
{via_url}
{message_id}
{timestamp}
{instance_id}
{sender_name}
{message}هذه المتغيرات مهمة لأنها تسمح ببناء محتوى يعتمد على البيانات الفعلية للحدث بدل كتابة قيمة ثابتة.
فعلى سبيل المثال، في سيناريو رسالة واردة يمكن أن تكون لدينا معلومات مثل:
Sender Name
Message
Message ID
Timestamp
Chat ID
Instance IDوبالتالي يصبح الـWebhook جزءًا من Workflow يمكنه تمرير بيانات الحدث إلى خطوة لاحقة.
استقبال البيانات أم إرسالها؟ وما الفرق؟
من أكثر النقاط التي تسبب ارتباكًا عند التعامل مع Webhooks هو الخلط بين استقبال البيانات وإرسال البيانات.
استقبال البيانات
في هذا السيناريو يبدأ الحدث من النظام الخارجي:
External System
↓
Webhook URL
↓
Whats360
↓
Processing
↓
WhatsAppمثال ذلك متجر إلكتروني يرسل بيانات طلب جديد إلى نقطة التكامل.
إرسال البيانات
هنا يبدأ الحدث من Whats360:
Whats360
↓
Event
↓
Webhook
↓
External Server
↓
External Systemمثل إرسال بيانات تحديث معين إلى نظام خارجي يحتاج إلى مزامنتها.
| المقارنة | استقبال البيانات | إرسال البيانات |
|---|---|---|
| مصدر الحدث | نظام خارجي | Whats360 |
| اتجاه البيانات | External → Whats360 | Whats360 → External |
| الاستخدام | استقبال Events من المتجر أو النظام | إرسال Events إلى السيرفر |
| الهدف | معالجة البيانات داخل Whats360 | مزامنة نظام خارجي |
هذه النقطة وحدها مهمة جدًا عند تصميم Architecture التكامل، لأن اختيار الاتجاه الخاطئ يعني أن النظامين قد يكونان متصلين نظريًا، لكن البيانات لا تتحرك بالطريقة المطلوبة.
قوالب Webhook الجاهزة للمتاجر الإلكترونية
تتضمن الصفحة قوالب جاهزة تساعد في تسريع عمليات الربط.
ومنها:
- طلب جديد – Shopify
- طلب جديد – WooCommerce
- Webhook مخصص
ويظهر بجانب كل قالب زر «استخدام» لتفعيله.
وجود القوالب الجاهزة مهم لأن المطور لا يحتاج دائمًا إلى تصميم كل عناصر التكامل من الصفر.
إذا كان السيناريو المطلوب مطابقًا للقالب، فإن استخدامه يمكن أن يكون نقطة بداية أسرع.
أما إذا كان النظام يحتاج إلى معالجة مختلفة للبيانات أو Workflow خاص، فيكون الـWebhook المخصص أكثر ملاءمة.
كيف تبدو بيانات الطلب داخل JSON Payload؟
توضح الصفحة مثالًا لبنية البيانات التي يمكن التعامل معها:
{
"id": {payload_id},
"order_number": {order_number},
"total_price": "{total_price}",
"customer": {
"first_name": "{customer_name}",
"phone": "{customer_phone}"
}
}هذه البيانات تمثل Payload، أي البيانات التي تنتقل أثناء عملية التكامل.
id
معرّف الطلب أو البيانات.
order_number
رقم الطلب الذي يمكن استخدامه في رسالة الإشعار أو في النظام الخارجي.
total_price
قيمة إجمالي الطلب.
customer.first_name
اسم العميل.
customer.phone
رقم الهاتف الذي يمكن استخدامه في سيناريو إرسال WhatsApp، بحسب منطق الـWorkflow.
Payload ليس هو الرسالة النهائية
هذه نقطة تقنية مهمة.
الـPayload يمثل البيانات الخام التي تصل إلى مرحلة المعالجة.
بينما رسالة WhatsApp قد تكون مثل:
تم استلام طلب جديد رقم #12345
العميل: محمد
إجمالي الطلب: 750 جنيهأي أن العملية يمكن تصورها كالتالي:
Order Event
↓
JSON Payload
↓
Extract Required Fields
↓
Message Template
↓
WhatsAppوهنا تظهر قيمة Webhook كطبقة تكامل، وليس مجرد وسيلة لنقل نص ثابت.
ربط Shopify بـWhats360 خطوة بخطوة
إذا كان لديك متجر Shopify وتريد إرسال بيانات الطلبات إلى Whats360، فإن الصفحة توضح مسار إعداد Webhook داخل Shopify.
ابدأ من إعدادات Shopify، ثم انتقل إلى:
Settings
↓
Notifications
↓
Webhooksبعد ذلك أنشئ Webhook واختر الحدث المطلوب.
في سيناريو الطلبات الجديدة، المثال الموضح هو:
orders/createثم يتم ضبط تنسيق البيانات على:
JSONوبعد ذلك يتم إدخال الرابط المناسب وحفظ إعداد الـWebhook.
ماذا يحدث بعد إنشاء الطلب؟
بعد إتمام الإعداد، تصبح دورة البيانات بهذا الشكل:
Customer
↓
Creates Order
↓
Shopify
↓
orders/create
↓
JSON Payload
↓
Webhook
↓
Whats360
↓
Process Data
↓
WhatsApp Notificationوبذلك لا يحتاج الموظف إلى فتح لوحة Shopify في كل مرة لمتابعة الطلبات إذا كان الهدف هو إنشاء إشعارات آلية مرتبطة بالأحداث.
Whats360 كطبقة تكامل
إذا كان الهدف هو تحويل أحداث المتجر أو النظام إلى إشعارات WhatsApp تلقائية، يمكن استخدام طبقة Webhook في Whats360 كجزء من Architecture التكامل.
ربط WooCommerce بنفس المنطق
يمكن تطبيق نفس فكرة التكامل مع WooCommerce.
المبدأ الأساسي لا يتغير:
WooCommerce
↓
Order Event
↓
Webhook
↓
Whats360
↓
Payload Processing
↓
WhatsAppلكن التفاصيل الخاصة بإنشاء الـWebhook والـEvent والـPayload تختلف بحسب النظام.
لذلك لا يصح افتراض أن إعداد WooCommerce مطابق حرفيًا لإعداد Shopify.
ما الذي يختلف؟
- طريقة إنشاء الـWebhook داخل المنصة.
- الأحداث المتاحة.
- شكل الـPayload.
- أسماء الحقول.
- طريقة معالجة البيانات.
ما الذي يبقى ثابتًا؟
المفهوم العام:
Event
↓
Webhook
↓
Payload
↓
Processing
↓
Actionوهذه هي الفكرة التي يجب أن يفهمها المطور عند بناء Integration بين أي نظام خارجي وWhats360.
متى تستخدم القالب الجاهز ومتى تستخدم Webhook مخصصًا؟
ليس كل تكامل يحتاج إلى نفس المستوى من البرمجة.
يمكن التفكير في القرار بهذه الطريقة:
استخدم القالب الجاهز عندما:
- يكون السيناريو مطابقًا للوظيفة المطلوبة.
- تكون البيانات المتوفرة كافية.
- لا تحتاج إلى معالجة مخصصة.
- تريد بدء التكامل بسرعة.
استخدم Webhook مخصصًا عندما:
- تحتاج إلى Payload مختلف.
- لديك نظام داخلي.
- تحتاج إلى Workflow خاص.
- تحتاج إلى معالجة إضافية للبيانات.
- تريد التحكم بشكل أكبر في منطق التكامل.
استخدم Middleware أو Server وسيط عندما:
يحتاج التكامل إلى منطق أكبر من مجرد نقل البيانات.
مثلًا:
Shopify
↓
Middleware
↓
Validate / Transform
↓
Whats360
↓
WhatsAppيمكن للطبقة الوسيطة أن تقوم بعمليات مثل تحويل البيانات أو تطبيق منطق أعمال قبل إرسالها إلى النظام التالي.
مثال عملي: إرسال إشعار WhatsApp عند إنشاء طلب
لنفترض أن متجرًا يريد إرسال إشعار عند وصول طلب جديد.
تبدأ العملية:
Customer places order
↓
Shopify / WooCommerce
↓
Webhook
↓
Whats360
↓
Payload Processing
↓
WhatsApp Messageويصل Payload مثل:
{
"id": 12345,
"order_number": 10025,
"total_price": "750",
"customer": {
"first_name": "محمد",
"phone": "01000000000"
}
}بعد استخراج البيانات المطلوبة يمكن تكوين رسالة مثل:
طلب جديد
رقم الطلب: #10025
العميل: محمد
الإجمالي: 750
تم تسجيل الطلب بنجاح.القيمة هنا ليست في إرسال الرسالة نفسها فقط، وإنما في أن الحدث أصبح Trigger يمكن بناء Workflow كامل حوله.
أين يدخل Secret في التكامل؟
عندما يستقبل سيرفر أو Endpoint طلب Webhook، فمن المهم أن تكون هناك طريقة للتأكد من أن الطلب مصدره المتوقع.
وهنا يأتي دور الـSecret.
التصور العام:
Webhook Request
↓
Read Verification Data
↓
Validate
↓
Accept / Reject
↓
Process Payloadلكن يجب التفريق بين فكرة استخدام Secret وبين تفاصيل آلية التحقق نفسها؛ فطريقة التحقق الفعلية تعتمد على آلية التكامل التي يتم تنفيذها.
القاعدة العملية: تعامل مع Secret باعتباره معلومة حساسة، ولا تضعه داخل Frontend مكشوف أو مستودع كود عام.
كيف تختبر Webhook قبل تشغيله في الإنتاج؟
من الأفضل عدم الانتقال مباشرة إلى التشغيل الفعلي قبل اختبار كل طبقة.
يمكن تقسيم الاختبار إلى:
Trigger
↓
HTTP Request
↓
Payload
↓
Validation
↓
Processing
↓
WhatsApp Action
↓
Resultوهذا التقسيم مهم جدًا عند حدوث مشكلة.
فإذا وصل الطلب إلى Whats360 ولكن لم تصل رسالة WhatsApp، فهذا لا يعني بالضرورة أن الـWebhook نفسه فشل.
قد تكون المشكلة في مرحلة أخرى من السلسلة.
لذلك يجب اختبار:
- هل حدث الـEvent؟
- هل تم إرسال HTTP Request؟
- هل وصل Payload؟
- هل البيانات صحيحة؟
- هل تم التحقق منها؟
- هل تمت معالجة البيانات؟
- هل تم تنفيذ خطوة WhatsApp؟
- ما النتيجة النهائية؟
بهذه الطريقة يصبح التشخيص أكثر دقة.
أخطاء شائعة في تصميم التكامل
هذه ليست بالضرورة أعطالًا في Whats360، وإنما أمثلة على نقاط يجب فحصها عند تصميم أو اختبار أي Webhook Integration.
URL غير صحيح
إذا كان Endpoint غير صحيح فلن تصل البيانات إلى الوجهة المطلوبة.
اختيار Event غير مناسب
قد يكون الـWebhook يعمل، لكن الحدث الذي تم اختياره لا يمثل العملية التي يريدها المطور.
Payload غير متوافق
قد تصل البيانات، لكن أسماء الحقول أو بنيتها لا تتوافق مع الـWorkflow الذي يعتمد عليها.
مشكلة في التحقق
إذا كان التكامل يعتمد على Secret، فيجب أن تكون آلية التحقق متوافقة بين الطرفين.
الخلط بين Incoming وOutgoing
قد يعتقد المطور أن Whats360 سيستقبل البيانات بينما الإعداد مصمم لإرسالها إلى سيرفر خارجي، أو العكس.
وصول Payload دون تنفيذ الإجراء النهائي
قد تنجح مرحلة:
Store → Webhook → Whats360لكن تفشل مرحلة:
Whats360 → WhatsAppولهذا يجب اختبار السلسلة على مراحل بدل اعتبار Webhook والتطبيق النهائي خطوة واحدة.
ثلاث Architectures لتكامل المتاجر مع Whats360
ليست كل المشاريع بحاجة إلى نفس البنية.
التكامل المباشر
Store
↓
Whats360
↓
WhatsAppمناسب عندما تكون المعالجة المطلوبة بسيطة.
التكامل عبر Middleware
Store
↓
Middleware
↓
Transform / Validate
↓
Whats360
↓
WhatsAppمفيد عندما تحتاج إلى تحويل البيانات أو تطبيق منطق برمجي قبل وصولها إلى Whats360.
بيئة متعددة الأنظمة
Shopify ─────┐
WooCommerce ─┤
CRM ─────────┤
ERP ─────────┤
↓
Integration Layer
↓
Whats360
↙ ↘
WhatsApp CRMهذا النموذج يناسب البيئات التي لا يكون فيها WhatsApp نظامًا منفصلًا عن بقية البنية، وإنما جزءًا من منظومة تشغيل أكبر.
Webhook أم API؟ الفرق الذي يحتاج المطور إلى فهمه
رغم ارتباط Webhook وAPI بالتكامل بين الأنظمة، فإن طريقة العمل مختلفة.
API غالبًا يعني أن نظامًا يطلب بيانات أو ينفذ عملية من خلال Request.
أما Webhook فيعتمد على إرسال إشعار أو بيانات عند حدوث Event.
بصيغة مبسطة:
API:
System A → "أعطني البيانات"
Webhook:
System A → "حدث شيء، وهذه بياناته"ولهذا غالبًا ما يكون Webhook مناسبًا جدًا للعمليات التي تعتمد على الأحداث، مثل إنشاء طلب جديد أو وصول رسالة أو حدوث تحديث.
وفي الأنظمة الكبيرة يمكن استخدام الاثنين معًا.
كيف تصبح صفحة Webhook جزءًا من Architecture أكبر؟
أفضل طريقة لفهم صفحة «إنشاء ويب هوك جديد» هي عدم النظر إليها كصفحة إعداد منفصلة.
هي تمثل نقطة داخل سلسلة أكبر:
Business Event
↓
Event Detection
↓
Webhook
↓
HTTP Request
↓
JSON Payload
↓
Validation
↓
Processing
↓
Automation
↓
WhatsApp / External Systemوهذا يوضح لماذا يحتاج المطور إلى فهم Event + URL + Payload + Security + Processing معًا.
اختيار URL وحده لا يبني Integration.
واختيار Event وحده لا ينفذ Automation.
والـPayload وحده لا يمثل رسالة WhatsApp.
القيمة تظهر عندما تعمل هذه المكونات معًا داخل Workflow واضح.
أسئلة شائعة حول Webhook في Whats360
ما هو Webhook في Whats360؟
هو آلية لربط Whats360 بنظام خارجي من خلال URL بحيث يتم نقل البيانات عند حدوث أحداث محددة.
ما الفرق بين استقبال وإرسال البيانات؟
استقبال البيانات يعني انتقال البيانات من النظام الخارجي إلى Whats360، بينما الإرسال يعني انتقال أحداث Whats360 إلى سيرفر خارجي.
ما وظيفة Secret؟
يستخدم كقيمة سرية يمكن الاعتماد عليها ضمن آلية التحقق من مصدر الطلبات وتأمين التكامل برمجيًا.
ما الأحداث المتاحة؟
تشمل الصفحة: رسالة واردة، فشل إرسال، رسالة مرسلة، وانتهاء الاشتراك.
ما المتغيرات الديناميكية؟
منها {chatid} و{message_id} و{timestamp} و{instance_id} و{sender_name} و{message} وغيرها من المتغيرات المتاحة في الصفحة.
هل يمكن ربط Shopify بـWhats360؟
نعم، تتضمن الصفحة قالبًا جاهزًا لطلبات Shopify، كما توضح إعداد Webhook لحدث orders/create باستخدام JSON.
هل يمكن ربط WooCommerce؟
نعم، تتضمن الصفحة قالبًا جاهزًا لطلب جديد – WooCommerce، مع إمكانية استخدام Webhook مخصص عند الحاجة إلى منطق مختلف.
ما هو JSON Payload؟
هو بنية البيانات التي تنتقل بين الأنظمة أثناء التكامل، مثل رقم الطلب وقيمته وبيانات العميل.
متى أستخدم Webhook مخصصًا؟
عندما لا يكون القالب الجاهز مناسبًا للبيانات أو الـWorkflow الذي تريد بناءه.
هل أحتاج إلى برمجة؟
يعتمد ذلك على السيناريو. القوالب الجاهزة تقلل الحاجة إلى بناء التكامل من الصفر، بينما السيناريوهات المخصصة أو التي تحتاج إلى Middleware قد تتطلب تطويرًا برمجيًا.
ماذا أفعل إذا وصل Payload ولم تصل رسالة WhatsApp؟
افصل مراحل الاختبار: تحقق أولًا من وصول الـPayload، ثم صحة البيانات، ثم المعالجة، ثم خطوة إرسال WhatsApp. وصول البيانات لا يعني تلقائيًا نجاح كل المراحل التالية.
هل تحتاج إلى ربط متجرك أو نظامك بالواتساب؟
إذا كان هدفك بناء Workflow يعتمد على Webhook وWhatsApp Automation، فإن Whats360 يمكن أن يكون جزءًا من بنية التكامل بين المتجر والواتساب.
الخلاصة
صفحة «إنشاء ويب هوك جديد» في Whats360 هي في الأساس واجهة لبناء Integration Layer بين المنصة والأنظمة الخارجية.
يمكن من خلالها تحديد بيانات التكامل، الـURL، الـSecret، والأحداث التي يتم التعامل معها، إلى جانب المتغيرات الديناميكية والقوالب الجاهزة لـShopify وWooCommerce.
وعند ربطها بمتجر إلكتروني تصبح الصورة أكثر وضوحًا:
Customer
↓
Order
↓
Shopify / WooCommerce
↓
Webhook
↓
JSON Payload
↓
Whats360
↓
Processing
↓
WhatsAppأما في المشاريع التي تحتاج إلى تحكم أكبر، فيمكن إضافة Middleware أو Integration Layer بين المتجر وWhats360 لمعالجة البيانات والتحقق منها قبل تنفيذ الإجراء النهائي.
وبالتالي، فإن أفضل طريقة لاستخدام Webhook ليست التفكير في «أين أضع الرابط؟»، وإنما التفكير في السؤال الأكبر:
ما الحدث الذي أريد التقاطه، وما البيانات التي أحتاجها، وإلى أين ستذهب، وما الإجراء الذي يجب أن يحدث بعدها؟
عندما تكون هذه السلسلة واضحة، يصبح تصميم التكامل نفسه أكثر بساطة، سواء كان الهدف ربط Shopify، WooCommerce، CRM، أو نظام برمجي مخصص مع Whats360.
