ما هو Webhook في n8n؟ شرح عملي للمبتدئين مع مثال خطوة بخطوة

آخر مراجعة: 1 سبتمبر 2026. إذا بدأت استخدام n8n، فستقابل كلمة Webhook بسرعة. الفكرة ليست معقدة: بدل أن يظل الـWorkflow يسأل خدمة خارجية كل دقيقة «هل لديك بيانات جديدة؟»، يمنحها عنوانًا تستدعيه عندما يحدث شيء فعليًا.

في هذا الدليل سنفهم Webhook عمليًا، ونبني مثالًا بسيطًا لاستقبال بيانات نموذج، ثم نغطي الفرق بين Test URL وProduction URL، طرق الاستجابة، وأهم قواعد الأمان قبل استخدامه مع بيانات العملاء.

ما هو Webhook ببساطة؟

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

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

Webhook أم Polling: ما الفرق؟

الأسلوب	كيف يعمل؟	متى يناسبك؟
Webhook	الخدمة ترسل البيانات عند وقوع الحدث	عندما تدعم الخدمة إشعارات HTTP وتحتاج استجابة سريعة
Polling	الـWorkflow يفحص الخدمة دوريًا بحثًا عن جديد	عندما لا توفر الخدمة Webhook أو تحتاج فحصًا مجدولًا

الـWebhook غالبًا أكثر كفاءة للأحداث الفورية لأنه لا ينفذ عمليات فحص بلا داعٍ. لكن هذا لا يعني أنه الأفضل دائمًا؛ بعض الأنظمة لا تدعمه، وبعض العمليات مناسبة أكثر لجدول زمني.

مكونات Webhook في n8n

عندما تضيف Webhook node ستتعامل عادة مع أربعة عناصر أساسية:

1. HTTP Method: مثل GET أو POST. استقبال النماذج والبيانات المنظمة يستخدم POST كثيرًا.
2. Path: الجزء الذي يميز عنوان Webhook الخاص بك.
3. Authentication: وسيلة التحقق من أن الطلب قادم من مصدر مسموح عندما تحتاج حماية إضافية.
4. Response: ما الذي سيرسله n8n للطرف الذي استدعى الرابط.

للتعرف أولًا على مفهوم Workflow وTrigger وNodes، راجع دليل n8n للمبتدئين.

الفرق بين Test URL وProduction URL

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

الرابط	الغرض	الملاحظة الأساسية
Test URL	تجربة الطلب أثناء البناء	تستخدمه بينما تستمع عقدة Webhook للاختبار داخل المحرر
Production URL	الطلبات الحقيقية	يُستخدم مع Workflow مفعّل وجاهز للعمل

لا تضع Test URL داخل خدمة إنتاجية دائمة، ولا تعتبر نجاح الاختبار دليلًا أن رابط الإنتاج تم تفعيله. قبل الإطلاق نفّذ طلبًا حقيقيًا إلى Production URL وتأكد أن التنفيذ يظهر في سجل executions.

مثال عملي: نموذج عميل جديد → n8n

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

الخطوة 1: أنشئ Webhook

أضف Webhook node واختر POST. استخدم مسارًا واضحًا لا يكشف معلومات حساسة، مثل new-client-request. أثناء البناء استخدم Test URL.

الخطوة 2: أرسل طلبًا تجريبيًا

أرسل النموذج مرة واحدة وانظر إلى البيانات التي يستقبلها n8n. لا تفترض أن أسماء الحقول هي نفسها التي تراها في واجهة النموذج؛ راقب الـJSON الفعلي.

الخطوة 3: تحقق من البيانات

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

الخطوة 4: نفذ الإجراء

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

الخطوة 5: أرسل استجابة مفهومة

اجعل الطرف المستدعي يعرف أن الطلب وصل أو لماذا رُفض. لا ترسل دائمًا استجابة نجاح إذا كان الـWorkflow اكتشف أن البيانات ناقصة.

متى تحتاج Respond to Webhook؟

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

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

7 قواعد أمان قبل نشر Webhook

1. استخدم HTTPS: لا ترسل بيانات عملاء عبر اتصال غير مشفر.
2. فعّل المصادقة عندما تكون متاحة: لا تجعل رابطًا حساسًا مفتوحًا لمجرد أن عنوانه طويل.
3. تحقق من المدخلات: وجود JSON لا يعني أن البيانات موثوقة.
4. لا تضع الأسرار داخل الرابط: كلمات المرور ومفاتيح API مكانها Credentials أو آلية سرية مناسبة، لا query string مكشوفة.
5. قلّل البيانات: لا تجمع أو تمرر بيانات لا تحتاجها العملية.
6. حدد ما يحدث عند الخطأ: فشل عقدة واحدة يجب ألا يؤدي إلى نتيجة مضللة أو تكرار غير مقصود.
7. راجع السجلات بحذر: قد تحتوي executions على بيانات حساسة؛ اضبط الاحتفاظ والتنظيف وفق طبيعة عملك.

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

أخطاء شائعة وحلها

المشكلة	السبب المحتمل	ما الذي تفحصه؟
Test URL لا يستقبل شيئًا	العقدة لا تستمع للاختبار أو الطلب يذهب إلى رابط آخر	ابدأ الاستماع ثم أعد إرسال الطلب
Production URL لا يعمل	الـWorkflow غير مفعّل	تأكد من حالة Active ومن الرابط المستخدم
البيانات تصل ناقصة	شكل payload مختلف عن توقعك	راجع body وheaders والحقول الفعلية
الطلب يتكرر	الخدمة الخارجية تعيد المحاولة بعد عدم تلقي استجابة مناسبة	راجع زمن وكود الاستجابة وسياسة retries
طلبات غير مرغوبة	Webhook مفتوح بلا تحقق	أضف authentication أو تحققًا من التوقيع/المصدر عندما تدعمه الخدمة

هل Webhook يحتاج n8n Cloud أم Self-Hosted؟

كلاهما يستطيع تشغيل Webhooks، لكن البيئة المستضافة ذاتيًا تحتاج أن يكون n8n قابلًا للوصول من الإنترنت بطريقة صحيحة وآمنة وأن تكون إعدادات النطاق وHTTPS والـproxy سليمة. قبل اختيار البيئة راجع مقارنة n8n Cloud وSelf‑Hosted من حيث التكلفة والخصوصية والصيانة.

هل يستحق تحويل المهمة إلى Webhook؟

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

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

Checklist قبل الانتقال للإنتاج

• هل تستخدم Production URL الصحيح؟
• هل الـWorkflow مفعّل؟
• هل اختبرت payload صالحًا وآخر ناقصًا؟
• هل الاستجابة مناسبة للطرف المستدعي؟
• هل المصادقة أو التحقق من المصدر كافيان؟
• هل توجد بيانات حساسة لا داعي لحفظها في executions؟
• هل تعرف ماذا سيحدث عند فشل عقدة لاحقة؟
• هل اختبرت العملية كاملة من المصدر إلى النتيجة النهائية؟

المصدر الرسمي

راجع دائمًا توثيق n8n الحالي قبل بناء Workflow إنتاجي، خصوصًا لأن خيارات العقدة قد تتغير مع الإصدارات: n8n Docs — Webhook node.

هذا الدليل تعليمي عام. إعدادات الأمان والاستضافة تختلف حسب الخدمة والبيانات والبنية التي تعمل عليها.