HTTP Request في n8n للمبتدئين: كيف تربط أي API خطوة بخطوة

مراجعة: 7 سبتمبر 2026

عقدة HTTP Request في n8n هي الجسر الذي يسمح لك بربط Workflow بأي خدمة تملك API تقريبًا، حتى لو لم يكن لها Node جاهز داخل n8n. إذا فهمت أربع أفكار فقط — عنوان الـEndpoint، نوع الطلب، المصادقة، وبنية البيانات — ستتمكن من بناء تكاملات عملية بدل الاعتماد الكامل على القوالب الجاهزة.

الخلاصة السريعة: تبدأ بتحديد Endpoint من توثيق الخدمة، تختار GET أو POST أو غيره، تضيف Authentication عند الحاجة، ثم ترسل أو تستقبل JSON وتختبر الاستجابة قبل ربطها ببقية الـWorkflow.

ما هي عقدة HTTP Request في n8n؟

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

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

متى تحتاج HTTP Request بدل Node جاهز؟

• عندما لا توجد عقدة رسمية للخدمة داخل n8n.
• عندما تكون العقدة الموجودة محدودة ولا تعرض Endpoint تحتاجه.
• عندما تريد استخدام إصدار API أحدث من الذي تدعمه العقدة الجاهزة.
• عندما تبني تكاملًا مخصصًا لعميل أو خدمة داخلية.
• عندما تريد التحكم الكامل في Headers وQuery Parameters وBody.

قبل أن تبدأ: افهم مكونات طلب API

أي طلب API عملي يتكون غالبًا من العناصر التالية:

العنصر	وظيفته	مثال
Method	نوع العملية	GET / POST / PUT / PATCH / DELETE
URL	عنوان الـEndpoint	https://api.example.com/v1/tasks
Authentication	إثبات الهوية والصلاحية	API Key أو Bearer Token
Headers	بيانات إضافية للطلب	Content-Type: application/json
Query Parameters	مرشحات تُضاف إلى الرابط	?status=open&limit=20
Body	البيانات المرسلة	JSON عند إنشاء أو تحديث سجل

الخطوة 1: أضف عقدة HTTP Request

1. افتح Workflow جديدًا أو موجودًا.
2. أضف Node جديدة وابحث عن HTTP Request.
3. حدد Method المناسب.
4. الصق عنوان الـURL من توثيق الـAPI.
5. اترك Authentication على None فقط إذا كان الـEndpoint عامًا فعلًا.

الخطوة 2: اختر GET أو POST أو PUT أو DELETE

الخطأ الأكثر شيوعًا عند المبتدئين هو استخدام Method غير مطابق لتوثيق الخدمة. القاعدة العامة:

• GET: قراءة بيانات دون تغييرها.
• POST: إنشاء مورد جديد أو تنفيذ عملية.
• PUT: استبدال مورد كامل غالبًا.
• PATCH: تعديل جزء من مورد قائم.
• DELETE: حذف مورد.

لا تعتمد على هذه القاعدة وحدها؛ المرجع النهائي دائمًا هو توثيق الـAPI الذي تتعامل معه.

الخطوة 3: إعداد Authentication بشكل صحيح

الـAPI قد يستخدم API Key أو Bearer Token أو Basic Auth أو OAuth2. لا تضع المفاتيح الحساسة كنص ثابت داخل عشر عقد مختلفة إذا كان بإمكانك استخدام Credentials في n8n؛ هذا يقلل احتمال تسريبها ويجعل تحديثها أسهل.

في Bearer Token مثلًا، تكون الفكرة أن الطلب يحتوي على Header يشبه:

Authorization: Bearer YOUR_TOKEN

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

الخطوة 4: إرسال Query Parameters وHeaders

إذا كان الـEndpoint يدعم البحث أو التصفية، أضف Query Parameters كحقول مستقلة. مثال:

status = open
limit = 20

سيصبح الطلب مكافئًا تقريبًا لـ:

https://api.example.com/v1/tasks?status=open&limit=20

أما Headers فتُستخدم عادة للمصادقة، نوع المحتوى، الإصدار، أو متطلبات خاصة بالخدمة.

الخطوة 5: إرسال JSON في Body

عند استخدام POST أو PATCH ستحتاج كثيرًا إلى Body بصيغة JSON. مثال مبسط لإنشاء مهمة:

{
  "title": "متابعة العميل",
  "status": "open",
  "priority": "high"
}

في n8n يمكنك إدخال القيم ثابتة أو ربطها ببيانات عقدة سابقة باستخدام Expressions. مثلًا يمكن أن يأتي اسم العميل من Webhook أو Form أو Google Sheet.

مثال عملي: Webhook يستقبل طلبًا ثم يرسله إلى API

لنفترض أن لديك نموذجًا يستقبل اسم العميل وبريده، ثم تريد إنشاء Lead في نظام خارجي.

1. ابدأ بعقدة Webhook لاستقبال البيانات.
2. أضف HTTP Request بعدها.
3. اختر POST.
4. ضع Endpoint إنشاء Lead.
5. اضبط Authentication.
6. أرسل Body يحتوي على name وemail باستخدام Expressions من Webhook.
7. اختبر الطلب وتحقق من HTTP Status والاستجابة.

إذا لم تكن استخدمت Webhook من قبل، راجع شرح Webhook في n8n خطوة بخطوة.

كيف تقرأ JSON الناتج وتستخدمه في العقد التالية؟

الاستجابة غالبًا تكون JSON. افترض أن API يعيد:

{
  "id": 781,
  "name": "Ahmed",
  "status": "created"
}

يمكنك استخدام قيمة id في عقدة لاحقة عبر Expression بدل نسخها يدويًا. هذه النقطة هي ما يجعل Workflow ديناميكيًا: البيانات تنتقل من خطوة إلى أخرى دون تدخل يدوي. وللتعمق في قراءة الحقول والمصفوفات واستخدام $json، راجع دليل Expressions وJSON في n8n للمبتدئين.

أهم أكواد HTTP Status التي يجب أن تعرفها

الكود	المعنى العملي	ماذا تفعل؟
200	تم الطلب بنجاح	تابع Workflow
201	تم إنشاء مورد	استخدم البيانات الجديدة
400	الطلب غير صحيح	راجع Body والحقول المطلوبة
401	فشل Authentication	راجع المفتاح أو Token
403	لا توجد صلاحية كافية	راجع Scope أو صلاحيات الحساب
404	Endpoint أو Resource غير موجود	راجع الرابط والمعرف
429	تجاوزت Rate Limit	أبطئ الطلبات واستخدم Retry
500+	خطأ من الخادم	أعد المحاولة وفق سياسة مدروسة

أخطاء شائعة في HTTP Request داخل n8n

1. وضع API Key في المكان الخطأ

بعض الخدمات تطلبه في Header، وأخرى Query Parameter. اتبع التوثيق حرفيًا.

2. إرسال JSON بصيغة غير متوقعة

قد ينتظر الـAPI object بينما ترسل string، أو ينتظر Array بينما ترسل عنصرًا واحدًا.

3. تجاهل Rate Limits

نجاح 10 طلبات لا يعني نجاح 10,000 طلب. راقب حدود الخدمة واستخدم batching أو delays عند الحاجة. إذا كنت تتعامل مع عدد كبير من العناصر، راجع دليل Loop Over Items وBatching في n8n لفهم كيفية تقسيم العناصر إلى دفعات وضبط السرعة لتقليل أخطاء 429.

4. إعادة المحاولة بلا ضوابط

Retry العشوائي قد يكرر عمليات حساسة مثل إنشاء فاتورة أو إرسال رسالة مرتين. راجع دليل معالجة أخطاء n8n وRetry on Fail قبل تشغيل Workflow إنتاجي.

5. تخزين أسرار العملاء داخل الحقول

استخدم Credentials ولا تضع Tokens في Screenshots أو Logs أو مستندات العميل. لمزيد من السياق الأمني راجع دليل خصوصية بيانات العملاء.

Checklist قبل تشغيل التكامل في الإنتاج

• تأكد من أن Method مطابق للتوثيق.
• اختبر Endpoint ببيانات تجريبية أولًا.
• تحقق من Authentication والصلاحيات.
• لا تضع Secrets داخل نصوص يمكن مشاركتها.
• تعامل مع 429 و5xx بسياسة Retry مناسبة.
• حدد ما يحدث عند 400 و401 و403.
• اختبر Workflow ببيانات ناقصة وغير متوقعة.
• راقب احتمال تكرار العمليات عند إعادة التنفيذ.

متى تستخدم Node جاهز ومتى تستخدم HTTP Request؟

استخدم Node جاهزًا إذا كان يغطي العملية التي تحتاجها بوضوح؛ سيكون أسرع في الإعداد وأسهل للمبتدئ. استخدم HTTP Request عندما تحتاج Endpoint غير موجود، أو تحكمًا أعمق، أو تكاملًا مخصصًا. وإذا كنت لا تزال تقارن منصات الأتمتة، راجع مقارنة n8n وMake وZapier.

أسئلة شائعة

هل أحتاج معرفة البرمجة لاستخدام HTTP Request في n8n؟

لا تحتاج أن تكون مبرمجًا، لكن يجب أن تفهم أساسيات API وJSON وHTTP Methods. كلما زادت تعقيدات المصادقة والبيانات، أصبحت المعرفة التقنية أكثر فائدة.

ما الفرق بين Webhook وHTTP Request في n8n؟

Webhook يستقبل طلبًا من الخارج إلى n8n، بينما HTTP Request يرسل طلبًا من n8n إلى API خارجي. كثير من الـWorkflows تستخدم الاثنين معًا.

لماذا أحصل على 401 رغم أن الرابط صحيح؟

لأن 401 يرتبط عادة بالمصادقة، لا بالرابط نفسه. راجع Token أو API Key وطريقة تمريره وصلاحياته.

هل يمكن استخدام HTTP Request مع أي API؟

معظم واجهات HTTP/REST يمكن التعامل معها، بشرط أن تعرف Endpoint وطريقة Authentication وشكل الطلب المتوقع.

ما الخطوة التالية بعد هذا الدليل؟

طبّق تكاملًا صغيرًا من ثلاث عقد: Trigger أو Webhook، ثم HTTP Request، ثم عقدة تحفظ النتيجة أو ترسل إشعارًا. بعد ذلك انتقل إلى Expressions وJSON بشكل أعمق.

الخلاصة

إتقان HTTP Request ينقل استخدامك لـn8n من تشغيل عقد جاهزة إلى بناء تكاملات حقيقية. ابدأ بطلب GET بسيط، ثم POST مع JSON، وبعدها أضف Authentication ومعالجة الأخطاء. لا تجعل أول تجربة لك Workflow إنتاجيًا معقدًا؛ ابنِ طبقة واحدة، اختبرها، ثم وسّعها.