نود HTTP Request در N8N

نود HTTP Request یکی از قدرتمندترین و پرکاربردترین نودهای n8n است. با استفاده از این نود می‌توان به انواع APIها، سرویس‌های تحت وب، سامانه‌های داخلی و برنامه‌های شخص ثالث متصل شد، اطلاعات دریافت کرد، داده فرستاد، فایل آپلود کرد و حتی عملیات‌هایی مانند ورود، ثبت سفارش، ارسال پیام یا به‌روزرسانی اطلاعات را انجام داد.

هر زمان که برای یک سرویس نود اختصاصی در n8n وجود نداشته باشد، معمولاً HTTP Request بهترین راه برای اتصال آن سرویس به یک ورکفلو است.

معرفی نود HTTP Request در n8n

HTTP Request یک نود Core و از نوع Action است که امکان ارسال درخواست‌های HTTP و HTTPS را فراهم می‌کند. این نود می‌تواند از متدهای رایج مانند GET، POST، PUT، PATCH و DELETE استفاده کند و پاسخ API را به‌صورت JSON، متن یا فایل در اختیار مراحل بعدی ورکفلو قرار دهد.

دسته‌بندی نود

نوع: Action
دسته: Core Node
وظیفه اصلی: ارتباط با APIها و سرویس‌های مبتنی بر HTTP و HTTPS
ورودی: آیتم‌های JSON یا Binary از نود قبلی
خروجی: پاسخ API به‌صورت JSON، متن، فایل یا پاسخ کامل HTTP

اهمیت نود در ورکفلوها

بخش بزرگی از اتوماسیون‌های حرفه‌ای به ارتباط میان چند نرم‌افزار وابسته است. نود HTTP Request این ارتباط را حتی زمانی که یک نود اختصاصی برای سرویس موردنظر وجود ندارد، برقرار می‌کند. در نتیجه می‌توان تقریباً هر سرویسی را که API قابل دسترس دارد به n8n متصل کرد.

موارد استفاده

دریافت اطلاعات از یک API

برای دریافت نرخ ارز، اطلاعات آب‌وهوا، وضعیت سفارش‌ها، موجودی محصولات یا اطلاعات کاربران می‌توان یک درخواست GET به API مربوطه ارسال کرد.

Schedule Trigger برای اجرای زمان‌بندی‌شده
HTTP Request برای دریافت اطلاعات
Code یا Edit Fields برای پردازش داده‌ها
Google Sheets برای ذخیره نتیجه

ارسال اطلاعات فرم به یک نرم‌افزار CRM

اطلاعات دریافت‌شده از یک فرم یا Webhook را می‌توان با درخواست POST به CRM فرستاد و یک مشتری جدید ایجاد کرد.

Webhook برای دریافت فرم
HTTP Request برای ارسال اطلاعات به CRM
IF برای بررسی موفقیت عملیات
Slack یا Email برای ارسال اعلان

به‌روزرسانی سفارش یا محصول

با متدهای PUT یا PATCH می‌توان وضعیت سفارش، قیمت محصول، موجودی انبار یا مشخصات مشتری را در یک سرویس خارجی تغییر داد.

حذف اطلاعات

متد DELETE برای حذف رکوردها، فایل‌ها، کاربران یا منابع دیگر از API استفاده می‌شود. شناسه منبع معمولاً در URL قرار می‌گیرد.

آپلود و دانلود فایل

نود HTTP Request می‌تواند فایل Binary را با ساختار multipart/form-data یا به‌صورت مستقیم ارسال کند. همچنین می‌تواند پاسخ یک API را به شکل فایل دریافت کرده و برای ذخیره‌سازی، ارسال ایمیل یا انتقال به فضای ابری در اختیار نودهای بعدی قرار دهد.

ارسال پیام از طریق API

در سرویس‌هایی که نود اختصاصی ندارند، می‌توان از API برای ارسال پیامک، پیام‌رسان، اعلان Push یا پیام‌های سازمانی استفاده کرد.

اتصال به هوش مصنوعی

برای اتصال به مدل‌های زبانی، سرویس‌های تبدیل متن به تصویر، تبدیل گفتار به متن یا APIهای تحلیل محتوا می‌توان درخواست POST همراه با بدنه JSON ارسال کرد.

پارامترها و تنظیمات

نمایش برخی تنظیمات به نسخه n8n، متد انتخاب‌شده، نوع احراز هویت و فعال بودن گزینه‌های Query Parameters، Headers، Body و Options بستگی دارد.

Method

نوع داده: انتخابی
کاربرد: مشخص‌کردن نوع عملیات HTTP
مثال: انتخاب GET برای دریافت فهرست محصولات

متدهای رایج قابل استفاده عبارت‌اند از:

GET: دریافت اطلاعات بدون ایجاد تغییر در منبع
POST: ایجاد رکورد یا ارسال اطلاعات جدید
PUT: جایگزینی کامل اطلاعات یک منبع
PATCH: به‌روزرسانی بخشی از اطلاعات
DELETE: حذف یک منبع
HEAD: دریافت Headerهای پاسخ بدون دریافت بدنه
OPTIONS: بررسی متدها و قابلیت‌های قابل پشتیبانی در مقصد

انتخاب متد باید دقیقاً با مستندات API مقصد هماهنگ باشد. استفاده از POST به‌جای PUT یا PATCH ممکن است باعث خطای ۴۰۵ یا ایجاد رکورد تکراری شود.

URL

نوع داده: String
کاربرد: آدرس کامل Endpoint موردنظر
مثال: https://api.example.com/v1/users

URL می‌تواند ثابت یا پویا باشد. برای ساخت URL پویا می‌توان از Expression استفاده کرد.

مثال Expression: https://api.example.com/v1/users/{{$json.id}}

آدرس باید معمولاً با http یا https شروع شود. برای افزودن پارامترهایی مانند فیلتر و شماره صفحه، استفاده از بخش Query Parameters نسبت به ساخت دستی URL روش مطمئن‌تری است.

Authentication

نوع داده: انتخابی یا Credential
کاربرد: تعیین روش احراز هویت درخواست
مثال: استفاده از Header Auth برای ارسال API Key

گزینه‌های اصلی احراز هویت عبارت‌اند از:

None: برای APIهای عمومی و بدون احراز هویت
Predefined Credential Type: استفاده از Credential آماده یک سرویس پشتیبانی‌شده در n8n
Generic Credential Type: استفاده از روش‌های عمومی مانند Basic Auth، Header Auth، Query Auth، OAuth1 و OAuth2

اطلاعات حساس مانند رمز عبور، API Key و Access Token بهتر است در بخش Credentials ذخیره شوند و نباید مستقیماً داخل URL، Header یا بدنه ورکفلو قرار گیرند.

Send Query Parameters

نوع داده: Boolean
کاربرد: فعال‌کردن ارسال پارامترهای Query String
مثال: ارسال page=۲ و limit=۵۰

پارامترهای Query بعد از علامت سؤال در URL ارسال می‌شوند و معمولاً برای صفحه‌بندی، جست‌وجو، مرتب‌سازی و فیلترکردن نتایج کاربرد دارند.

Specify Query Parameters

نوع داده: انتخابی
کاربرد: تعیین روش تعریف Query Parameterها
حالت‌ها: Using Fields Below یا Using JSON

در حالت Fields Below هر پارامتر با Name و Value تعریف می‌شود. در حالت JSON می‌توان مجموعه پارامترها را به شکل یک شیء JSON وارد کرد.

{  "page": 1,  "limit": 20,  "status": "active"}

Query Parameter Name و Value

Name: نام پارامتر مورد انتظار API
Value: مقدار ثابت یا Expression
مثال: نام status و مقدار active

برای استفاده از داده نود قبلی می‌توان مقداری مانند {{$json.status}} را در فیلد Value قرار داد.

Send Headers

نوع داده: Boolean
کاربرد: فعال‌کردن ارسال Headerهای سفارشی
مثال: ارسال Authorization یا Content-Type

Headerها اطلاعات جانبی درخواست را مشخص می‌کنند. نوع داده ارسالی، زبان، نسخه API و توکن دسترسی معمولاً از طریق Header منتقل می‌شوند.

Specify Headers

نوع داده: انتخابی
کاربرد: تعریف Headerها با فیلدهای جداگانه یا JSON
حالت‌ها: Using Fields Below یا Using JSON

{  "Authorization": "Bearer ACCESS_TOKEN",  "Accept": "application/json",  "X-API-Version": "2026-01"}

اگر از Credential استفاده می‌شود، از تعریف دوباره Authorization خودداری شود؛ زیرا ممکن است مقدار Credential با Header دستی تداخل پیدا کند.

Header Name و Value

Name: نام Header مانند Accept یا X-API-Key
Value: مقدار Header به‌صورت ثابت یا Expression
مثال: Accept با مقدار application/json

Send Body

نوع داده: Boolean
کاربرد: فعال‌کردن بدنه درخواست
مثال: ارسال اطلاعات کاربر در یک درخواست POST

بدنه معمولاً در متدهای POST، PUT و PATCH استفاده می‌شود. برخی APIها برای DELETE نیز بدنه می‌پذیرند، اما این رفتار عمومی نیست و باید با مستندات API بررسی شود.

Body Content Type

نوع داده: انتخابی
کاربرد: مشخص‌کردن قالب داده ارسالی در بدنه

JSON

نوع داده: Object یا JSON
کاربرد: ارسال داده ساختاریافته با Content-Type برابر application/json
مثال: ایجاد یک کاربر در API

{  "name": "علی رضایی",  "email": "ali@example.com",  "active": true}

در حالت JSON باید ساختار داده معتبر باشد. استفاده از ویرگول اضافه، کوتیشن ناقص یا مقدار نامعتبر باعث خطای پیکربندی یا خطای ۴۰۰ در API می‌شود.

Form URLencoded

نوع داده: مجموعه Name و Value
کاربرد: ارسال داده با قالب application/x-www-form-urlencoded
مثال: دریافت توکن از بعضی سرویس‌های OAuth

داده در این حالت مشابه فرم‌های ساده وب ارسال می‌شود. نمونه مفهومی آن grant_type=client_credentials است.

Multipart Form-Data

نوع داده: متن و Binary
کاربرد: ارسال هم‌زمان فایل و فیلدهای متنی
مثال: آپلود تصویر همراه با عنوان و توضیحات

برای فایل باید نام فیلد مورد انتظار API و نام Property باینری موجود در ورودی مشخص شود. نام فیلد فایل ممکن است file، image، document یا مقدار دیگری باشد.

n8n Binary File

نوع داده: Binary
کاربرد: ارسال مستقیم فایل موجود در داده باینری n8n
مثال: ارسال فایل دریافت‌شده از Google Drive به API ذخیره‌سازی

نام Input Data Field Name باید با نام Property باینری خروجی نود قبلی مطابقت داشته باشد. نام متداول این Property برابر data است، اما ممکن است در هر ورکفلو متفاوت باشد.

Raw

نوع داده: String
کاربرد: ارسال بدنه خام بدون تبدیل خودکار
مثال: ارسال XML، متن ساده یا یک قالب اختصاصی

در حالت Raw باید Content-Type صحیح نیز تعیین شود؛ برای مثال application/xml برای XML یا text/plain برای متن ساده.

Import cURL

این قابلیت امکان تبدیل یک فرمان cURL به تنظیمات نود HTTP Request را فراهم می‌کند. با کپی‌کردن cURL از مستندات API، بخش‌هایی مانند URL، Method، Header و Body به‌صورت خودکار وارد نود می‌شوند.

پس از Import باید توکن‌ها، Cookieها، Headerهای غیرضروری و مقادیر محیط آزمایشی بررسی شوند. واردکردن cURL به معنی تضمین صحت یا امنیت درخواست نیست.

Response Format

نوع داده: انتخابی
کاربرد: تعیین نحوه پردازش پاسخ API
حالت‌های رایج: Autodetect، JSON، Text و File

در حالت Autodetect، n8n بر اساس Content-Type پاسخ تصمیم می‌گیرد. اگر API نوع محتوای نادرست برگرداند، بهتر است فرمت پاسخ به‌صورت دستی انتخاب شود.

Include Response Headers and Status

نوع داده: Boolean
کاربرد: اضافه‌کردن Status Code و Headerهای پاسخ به خروجی
مثال: بررسی کد ۲۰۱ پس از ایجاد موفق یک رکورد

در حالت عادی معمولاً بدنه پاسخ در خروجی قرار می‌گیرد. با فعال‌کردن این گزینه، خروجی شامل body، headers و statusCode خواهد بود.

Never Error

نوع داده: Boolean
کاربرد: جلوگیری از توقف نود برای کدهای پاسخ ناموفق HTTP
مثال: دریافت پاسخ ۴۰۴ و بررسی آن با نود IF

این گزینه خطاهای شبکه یا مشکلات داخلی اجرای نود را لزوماً خنثی نمی‌کند. کاربرد اصلی آن پردازش پاسخ‌هایی مانند ۴۰۰، ۴۰۴ یا ۵۰۰ به‌عنوان داده است.

Timeout

نوع داده: Number
کاربرد: تعیین حداکثر زمان انتظار برای پاسخ بر حسب میلی‌ثانیه
مثال: ۳۰۰۰۰ برای انتظار حداکثر ۳۰ ثانیه

Timeout بسیار کم باعث قطع درخواست‌های کند می‌شود. مقدار بسیار زیاد نیز می‌تواند اجرای ورکفلو را برای مدت طولانی درگیر نگه دارد.

Redirects

Follow Redirects: دنبال‌کردن پاسخ‌های انتقال مانند ۳۰۱، ۳۰۲، ۳۰۷ و ۳۰۸
Max Redirects: تعیین حداکثر تعداد انتقال‌های قابل دنبال‌کردن
مثال: دنبال‌کردن لینک دانلودی که ابتدا به یک URL موقت هدایت می‌شود

Redirectهای زیاد یا حلقه‌ای می‌توانند نشانه تنظیم نادرست URL یا سرویس مقصد باشند.

Ignore SSL Issues

نوع داده: Boolean
کاربرد: نادیده‌گرفتن برخی خطاهای گواهی SSL
مثال: اتصال آزمایشی به یک سرویس داخلی با گواهی Self-Signed

فعال‌کردن این گزینه در محیط عملیاتی توصیه نمی‌شود؛ زیرا اعتبار گواهی مقصد بررسی نخواهد شد و خطر حملات واسط افزایش پیدا می‌کند.

Lowercase Headers

نوع داده: Boolean
کاربرد: تبدیل نام Headerهای پاسخ به حروف کوچک
مثال: دسترسی یکنواخت به content-type در Expressionها

Proxy

نوع داده: String
کاربرد: ارسال درخواست از طریق پراکسی
مثال: http://proxy.example.com:8080

پشتیبانی و نحوه نمایش این گزینه می‌تواند به نسخه n8n و تنظیمات محیط اجرا وابسته باشد. اطلاعات حساس پراکسی بهتر است از طریق تنظیمات امن زیرساخت مدیریت شود.

Batching

Items per Batch: تعداد آیتم‌هایی که در هر گروه پردازش می‌شوند
Batch Interval: فاصله زمانی میان گروه‌ها
کاربرد: کاهش احتمال عبور از Rate Limit سرویس مقصد
مثال: ارسال ۱۰ درخواست در هر گروه با فاصله یک ثانیه

Batching تعداد کل درخواست‌ها را کاهش نمی‌دهد؛ بلکه زمان‌بندی اجرای آن‌ها را کنترل می‌کند.

Array Format in Query Parameters

نوع داده: انتخابی
کاربرد: تعیین نحوه تبدیل آرایه‌ها در Query String
مثال: ارسال چند مقدار برای پارامتر category

APIها ممکن است آرایه را با تکرار نام پارامتر، براکت یا اندیس دریافت کنند. قالب انتخابی باید با مستندات مقصد سازگار باشد. نام دقیق حالت‌ها ممکن است در نسخه‌های مختلف n8n متفاوت باشد.

Pagination

Pagination برای دریافت اطلاعاتی استفاده می‌شود که API آن‌ها را در چند صفحه برمی‌گرداند. بدون صفحه‌بندی، معمولاً فقط صفحه اول داده‌ها دریافت می‌شود.

Pagination Mode: روش تعیین صفحه یا URL بعدی
Update a Parameter in Each Request: تغییر شماره صفحه، Offset، Cursor، Header یا بخشی از درخواست در هر مرحله
Response Contains Next URL: استخراج URL صفحه بعد از پاسخ فعلی
Pagination Complete When: تعیین شرط پایان صفحه‌بندی
Limit Pages Fetched: محدودکردن تعداد صفحات دریافتی
Interval Between Requests: ایجاد فاصله زمانی میان درخواست‌های صفحه‌بندی

برای ساخت منطق صفحه‌بندی می‌توان از متغیرهای داخلی مانند شماره صفحه جاری و اطلاعات پاسخ قبلی استفاده کرد. نام دقیق متغیرها و گزینه‌های در دسترس باید با نسخه نصب‌شده n8n و راهنمای Expression همان نود بررسی شود.

ورودی‌ها و خروجی‌ها

ورودی نود

نود HTTP Request می‌تواند بدون ورودی و به‌عنوان اولین نود عملیاتی پس از Trigger اجرا شود یا آیتم‌های نود قبلی را دریافت کند. در حالت عادی، درخواست برای هر آیتم ورودی اجرا می‌شود.

نمونه ورودی از نود قبلی:

[  {    "id": 125,    "name": "محصول آزمایشی",    "price": 850000,    "status": "active"  }]

برای استفاده از این مقادیر در URL یا Body می‌توان Expressionهایی مانند {{$json.id}} و {{$json.price}} را به کار برد.

ورودی Binary

برای ارسال فایل، نود قبلی باید داده Binary تولید کرده باشد. فایل ممکن است از نودهایی مانند Read/Write Files from Disk، Google Drive، Telegram، Webhook یا یک HTTP Request دیگر دریافت شده باشد.

نمونه ساختار مفهومی یک آیتم دارای فایل:

{  "json": {    "documentId": 42  },  "binary": {    "data": {      "fileName": "invoice.pdf",      "mimeType": "application/pdf"    }  }}

خروجی JSON

اگر پاسخ API از نوع JSON باشد، خروجی نود نیز به‌صورت داده JSON در اختیار نود بعدی قرار می‌گیرد.

[  {    "id": 125,    "name": "محصول آزمایشی",    "price": 850000,    "status": "active"  }]

خروجی کامل پاسخ HTTP

با فعال‌کردن Include Response Headers and Status، ساختار خروجی معمولاً شامل بدنه، Headerها و کد وضعیت است.

{  "body": {    "id": 125,    "status": "created"  },  "headers": {    "content-type": "application/json"  },  "statusCode": 201,  "statusMessage": "Created"}

جزئیات دقیق ساختار ممکن است بر اساس نسخه n8n، نوع پاسخ و تنظیمات نود متفاوت باشد.

خروجی Text

اگر Response Format روی Text قرار گیرد، پاسخ متنی API به‌عنوان یک فیلد متنی در خروجی قرار می‌گیرد. این حالت برای HTML، XML، CSV خام یا پاسخ‌های ساده مناسب است.

خروجی File

در حالت File، پاسخ در بخش Binary آیتم ذخیره می‌شود. سپس می‌توان آن را به Google Drive، Amazon S3، ایمیل، تلگرام یا فضای ذخیره‌سازی دیگری فرستاد.

تعداد درخواست‌ها بر اساس ورودی

اگر ۱۰۰ آیتم وارد نود شود، نود معمولاً ۱۰۰ درخواست جداگانه ارسال می‌کند. این رفتار باید هنگام کار با APIهای دارای محدودیت درخواست، هزینه مصرف یا زمان پاسخ زیاد در نظر گرفته شود.

نکات پیشرفته و ترفندها

استفاده از Expression برای درخواست‌های پویا

تقریباً تمام فیلدهای مهم نود می‌توانند با Expression مقداردهی شوند. برای مثال شناسه کاربر را می‌توان از خروجی نود قبلی داخل URL قرار داد.

https://api.example.com/users/{{$json.userId}}

همچنین می‌توان Header، Query Parameter و Body را بر اساس داده‌های هر آیتم ساخت.

ساخت بدنه کامل با Expression

در درخواست‌های پیچیده می‌توان کل بدنه JSON را با استفاده از داده‌های نود قبلی تولید کرد. این روش برای آرایه‌ها، اشیای تو در تو و فیلدهای اختیاری مناسب است.

{  "customer": {    "id": "{{$json.customerId}}",    "name": "{{$json.customerName}}"  },  "items": "{{$json.items}}"}

اگر مقدار Expression یک آرایه یا Object است، باید به‌عنوان داده واقعی JSON ارسال شود و نه رشته‌ای که ظاهر JSON دارد. پیش‌نمایش Expression برای بررسی نوع مقدار اهمیت زیادی دارد.

مدیریت Rate Limit

بسیاری از APIها تعداد درخواست مجاز را در دقیقه یا ثانیه محدود می‌کنند. برای کنترل این محدودیت می‌توان از روش‌های زیر استفاده کرد:

فعال‌کردن Batching و تعیین فاصله زمانی
استفاده از Loop Over Items برای پردازش گروهی
استفاده از Wait بین درخواست‌ها
بررسی Headerهایی مانند Retry-After
اجرای مجدد کنترل‌شده در خطاهای ۴۲۹

پردازش خطا بدون توقف ورکفلو

با فعال‌کردن Never Error یا تنظیمات مدیریت خطای نود، می‌توان پاسخ ناموفق را به IF یا Switch فرستاد و بر اساس statusCode تصمیم گرفت.

کدهای ۲۰۰ تا ۲۹۹ برای عملیات موفق
کد ۴۰۰ برای داده نامعتبر
کدهای ۴۰۱ و ۴۰۳ برای مشکل دسترسی
کد ۴۰۴ برای پیدانشدن منبع
کد ۴۲۹ برای عبور از محدودیت درخواست
کدهای ۵۰۰ تا ۵۹۹ برای خطای سمت سرور

صفحه‌بندی مبتنی بر Cursor

برخی APIها به‌جای page و limit از Cursor استفاده می‌کنند. در این حالت مقدار Cursor صفحه بعد از پاسخ فعلی استخراج و در Query Parameter یا Body درخواست بعدی قرار می‌گیرد. شرط پایان زمانی است که nextCursor خالی یا null باشد.

تازه‌سازی خودکار Token

برای APIهای مبتنی بر OAuth2 بهتر است از Credential استاندارد OAuth2 استفاده شود تا مدیریت Access Token و Refresh Token به‌صورت امن‌تر انجام شود. در احراز هویت سفارشی می‌توان یک HTTP Request برای دریافت توکن اجرا کرد و سپس توکن را در درخواست اصلی به کار برد.

ساخت Retry کنترل‌شده

برای خطاهای موقت مانند ۴۲۹، ۵۰۲، ۵۰۳ و ۵۰۴ می‌توان اجرای مجدد را با فاصله زمانی انجام داد. Retry نباید برای همه خطاها بدون محدودیت فعال شود؛ زیرا خطاهای دائمی مانند ۴۰۰ معمولاً با تکرار درخواست حل نمی‌شوند.

استفاده از Edit Fields قبل از HTTP Request

قرار دادن نود Edit Fields قبل از HTTP Request باعث می‌شود داده‌های موردنیاز تمیز، نام‌گذاری و محدود شوند. این کار از ارسال ناخواسته اطلاعات اضافی یا حساس جلوگیری می‌کند.

بررسی داده با IF و Switch

پس از دریافت پاسخ، نود IF می‌تواند موفقیت یا شکست عملیات را بررسی کند. نود Switch نیز برای مدیریت چند وضعیت مانند created، pending، rejected و failed مناسب است.

ذخیره اطلاعات پاسخ برای عیب‌یابی

ثبت statusCode، بخشی از body، زمان اجرا و شناسه درخواست API در دیتابیس یا سیستم ثبت رخداد، عیب‌یابی ورکفلوهای عملیاتی را ساده‌تر می‌کند. توکن‌ها، Cookieها و اطلاعات شخصی نباید بدون ضرورت در گزارش‌ها ذخیره شوند.

کنترل هم‌زمانی

ارسال تعداد زیادی درخواست هم‌زمان ممکن است API مقصد یا سرور n8n را تحت فشار قرار دهد. Batching، صف اجرا، محدودکردن Concurrency و تقسیم داده‌ها به گروه‌های کوچک‌تر برای ورکفلوهای حجیم اهمیت دارد.

جلوگیری از ایجاد رکورد تکراری

در عملیات حساس مانند پرداخت، ثبت سفارش یا صدور فاکتور بهتر است از Idempotency Key استفاده شود؛ البته API مقصد باید این قابلیت را پشتیبانی کند. این کلید معمولاً در Header ارسال می‌شود و مانع اجرای دوباره یک عملیات یکسان می‌گردد.

محدودیت‌ها و خطاها

خطای ۴۰۰ Bad Request

این خطا معمولاً به دلیل بدنه نامعتبر، نام اشتباه فیلدها، نوع داده نادرست یا نبود پارامتر اجباری رخ می‌دهد.

ساختار Body با مستندات API مقایسه شود.
نوع مقادیر مانند String، Number و Boolean بررسی شود.
JSON از نظر کوتیشن، براکت و ویرگول بررسی شود.
Content-Type صحیح انتخاب شود.

خطای ۴۰۱ Unauthorized

توکن، API Key یا اطلاعات ورود نامعتبر، منقضی یا ارسال‌نشده است.

Credential بررسی شود.
پیشوند Bearer در صورت نیاز اضافه شود.
تاریخ انقضای Access Token بررسی شود.
از وجود فاصله اضافی در Header جلوگیری شود.

خطای ۴۰۳ Forbidden

احراز هویت انجام شده، اما حساب یا توکن مجوز انجام عملیات را ندارد.

Scopeهای OAuth بررسی شوند.
سطح دسترسی حساب سرویس بررسی شود.
محدودیت IP، دامنه یا محیط اجرایی بررسی شود.

خطای ۴۰۴ Not Found

URL، Endpoint یا شناسه منبع صحیح نیست.

نسخه API در URL بررسی شود.
شناسه پویا در Expression کنترل شود.
وجود اسلش اضافی یا بخش حذف‌شده از مسیر بررسی شود.

خطای ۴۰۵ Method Not Allowed

متد انتخاب‌شده برای Endpoint مجاز نیست. برای نمونه، ممکن است Endpoint فقط POST را بپذیرد اما درخواست با GET ارسال شده باشد.

خطای ۴۱۵ Unsupported Media Type

فرمت بدنه یا Content-Type مورد قبول API نیست.

JSON، Form URLencoded یا Multipart مطابق مستندات انتخاب شود.
Header مربوط به Content-Type با بدنه هماهنگ باشد.
در آپلود فایل، نام فیلد و MIME Type بررسی شود.

خطای ۴۲۲ Unprocessable Entity

ساختار درخواست قابل خواندن است، اما مقادیر آن از نظر اعتبارسنجی قابل قبول نیستند. ایمیل نامعتبر، فیلد اجباری خالی یا مقدار خارج از محدوده از دلایل متداول این خطا هستند.

خطای ۴۲۹ Too Many Requests

تعداد درخواست‌ها از محدودیت API عبور کرده است.

Batching یا Wait استفاده شود.
Header مربوط به Retry-After بررسی شود.
تعداد آیتم‌های ورودی کاهش یابد.
Retry با فاصله افزایشی و تعداد محدود انجام شود.

خطاهای ۵۰۰، ۵۰۲، ۵۰۳ و ۵۰۴

این خطاها معمولاً در سمت سرویس مقصد رخ می‌دهند و ممکن است موقت باشند. Retry کنترل‌شده، افزایش Timeout و بررسی وضعیت سرویس مقصد راهکارهای متداول هستند.

خطای Timeout

سرویس مقصد در زمان تعیین‌شده پاسخ نداده است.

Timeout افزایش داده شود.
حجم پاسخ یا فایل کاهش یابد.
عملیات طولانی به روش غیرهم‌زمان API اجرا شود.
اتصال شبکه و DNS سرور n8n بررسی شود.

خطاهای SSL

گواهی منقضی، Self-Signed، نامعتبر یا ناسازگار با دامنه می‌تواند باعث قطع اتصال شود. راهکار اصلی، اصلاح گواهی در سرویس مقصد است. Ignore SSL Issues فقط برای آزمایش یا شبکه‌های کنترل‌شده مناسب است.

خطاهای DNS و اتصال

اگر سرور n8n نتواند دامنه مقصد را Resolve کند یا به پورت مقصد دسترسی داشته باشد، درخواست اجرا نمی‌شود. Firewall، Proxy، Docker Network، DNS و محدودیت‌های شبکه باید بررسی شوند.

محدودیت حجم فایل و پاسخ

فایل‌های بزرگ حافظه، فضای ذخیره‌سازی و زمان اجرای بیشتری مصرف می‌کنند. محدودیت دقیق به تنظیمات n8n، روش ذخیره Binary Data، Reverse Proxy و زیرساخت اجرا وابسته است.

تفاوت شبکه داخلی و عمومی

آدرسی مانند localhost از دید کانتینر n8n به خود کانتینر اشاره می‌کند، نه لزوماً به سیستم میزبان. در محیط Docker باید نام سرویس، شبکه مشترک یا آدرس مناسب میزبان استفاده شود.

ارسال یک درخواست برای هر آیتم

وجود هزاران آیتم ورودی می‌تواند هزاران درخواست ایجاد کند. این رفتار ممکن است باعث افزایش هزینه API، عبور از Rate Limit و طولانی‌شدن اجرای ورکفلو شود.

محدودیت API مقصد

نود HTTP Request نمی‌تواند محدودیت‌های API مقصد را حذف کند. محدودیت تعداد درخواست، Scope دسترسی، فرمت فایل، اندازه Body، تعداد نتایج و سیاست امنیتی همچنان توسط سرویس مقصد اعمال می‌شود.

ریسک افشای اطلاعات حساس

قرار دادن Token در URL ممکن است باعث ثبت آن در Logها، تاریخچه مرورگر، پراکسی یا سیستم مانیتورینگ شود. استفاده از Credentials و Headerهای امن روش مناسب‌تری است.

ریسک SSRF در URLهای پویا

اگر URL مستقیماً از ورودی کاربر ساخته شود، امکان ارسال درخواست به مقصدهای ناخواسته یا منابع داخلی وجود دارد. دامنه‌ها و پروتکل‌های مجاز باید اعتبارسنجی شوند و URL ورودی نباید بدون کنترل استفاده شود.

ایده‌ها

سامانه پایش قیمت رقبا: دریافت دوره‌ای قیمت محصولات از API، مقایسه با قیمت فروشگاه و ثبت تغییرات در Google Sheets یا دیتابیس.
مرکز یکپارچه اعلان‌ها: دریافت رویداد از Webhook و ارسال آن از طریق API پیامک، پیام‌رسان، ایمیل یا سرویس Push بر اساس نوع رویداد.
گزارش روزانه وضعیت سرویس‌ها: بررسی چند Endpoint، ثبت Status Code و زمان پاسخ و ارسال گزارش خرابی به Slack یا Telegram.
پردازش هوشمند اسناد: دریافت فایل، ارسال آن به API OCR یا هوش مصنوعی، استخراج اطلاعات و ذخیره نتیجه در CRM یا دیتابیس.
همگام‌سازی موجودی چند فروشگاه: دریافت موجودی از سیستم مرکزی و به‌روزرسانی محصولات در چند فروشگاه از طریق APIهای جداگانه.