نود Facebook Graph API در N8N

نود Facebook Graph API در N8N

اگر می‌خواهید داده‌های فیسبوک و اینستاگرام (زیرمجموعه Meta) را در ورکفلوهای اتوماتیک به کار بگیرید—از خواندن آمار و اینسایت‌ها تا مدیریت صفحات و انتشار محتوا—Facebook Graph API یکی از مهم‌ترین درگاه‌هاست. در N8N معمولاً با استفاده از نودهای HTTP و OAuth2 می‌توان به Graph API وصل شد و عملیات‌های مختلف را روی Page، Post، Comment، Insights و… انجام داد.

معرفی نود در N8N

در N8N به‌صورت پیش‌فرض «نود اختصاصی با نام Facebook Graph API» ممکن است در همه نسخه‌ها وجود نداشته باشد، اما به‌صورت عملی، پیاده‌سازی Graph API با این ترکیب انجام می‌شود:

  • HTTP Request برای ارسال درخواست‌های GET/POST به Graph API
  • OAuth2 (Credential) برای دریافت و مدیریت Access Token
  • Set / Function / Code برای ساخت بدنه درخواست، پارامترها، و تبدیل داده‌ها

دسته‌بندی نود: Integration (از طریق HTTP Request) + Action (ارسال/به‌روزرسانی داده) + Function (تبدیل داده‌ها)

کاربرد اصلی: اتصال اتوماتیک N8N به اکوسیستم Meta (Facebook/Instagram) برای خواندن داده‌ها، انتشار محتوا، مدیریت کامنت‌ها و دریافت گزارش‌ها.

اهمیت در ورکفلوها: Graph API معمولاً مرکز یکپارچه‌سازی داده‌های مارکتینگ است؛ به کمک آن می‌توان گزارش‌گیری خودکار، انتشار زمان‌بندی‌شده و مانیتورینگ تعاملات را بدون دخالت دستی انجام داد.

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

1) گزارش‌گیری روزانه از Insights پیج

  • خواندن متریک‌هایی مثل reach، impressions، page views
  • ارسال خروجی به Google Sheets یا Airtable
  • ساخت داشبورد ساده با ذخیره‌سازی منظم داده‌ها

2) مانیتورینگ کامنت‌های پست‌ها و پاسخ خودکار

  • خواندن کامنت‌های جدید از یک پست
  • فیلتر کردن کامنت‌ها (مثلاً دارای کلمات کلیدی)
  • ارسال پاسخ یا ثبت تیکت در ابزارهای پشتیبانی

3) انتشار محتوا در صفحه (Page) از روی تقویم محتوا

  • دریافت پست آماده از Notion/Google Sheet
  • ارسال درخواست به endpoint انتشار پست
  • ثبت نتیجه و لینک پست منتشرشده

4) دریافت لیست اکانت‌های اینستاگرام متصل به Page

  • خواندن IG User مربوط به Page برای انجام عملیات‌های IG Graph API
  • استفاده در سناریوهای گزارش‌گیری و مدیریت محتوا

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

  • Schedule Trigger + HTTP Request: گزارش‌گیری زمان‌بندی‌شده
  • Webhook + HTTP Request: پردازش رویدادهای دریافتی (در صورت استفاده از Webhooks متا)
  • IF + Function: شرط‌گذاری روی داده‌های Insight یا متن کامنت
  • Google Sheets / Airtable: ذخیره‌سازی خروجی و ایجاد تاریخچه
  • Slack / Telegram / Email: ارسال هشدار و گزارش

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

در عمل، پارامترهای Graph API را در نود HTTP Request تنظیم می‌کنید. در ادامه فیلدهای مهم به‌صورت کاربردی آمده است.

1) Method (روش درخواست)

  • نوع داده: String (GET/POST/DELETE)
  • کاربرد: GET برای خواندن داده، POST برای ایجاد/ارسال، DELETE برای حذف
  • مثال عملی: GET برای خواندن insights، POST برای انتشار پست

2) URL (آدرس endpoint)

  • نوع داده: String
  • کاربرد: مسیر Graph API شامل نسخه و resource
  • مثال عملی: https://graph.facebook.com/v20.0/{page-id}/insights

نکته مهم: نسخه Graph (مثلاً v20.0) را مشخص کنید تا تغییرات آینده API کمتر ورکفلو را بشکند.

3) Authentication (احراز هویت)

  • نوع داده: تنظیمات Credential
  • کاربرد: ارسال Access Token به API
  • مثال عملی: استفاده از OAuth2 Credential یا ارسال Bearer Token در Header

نکته مهم: در Graph API معمولاً با Access Token سروکار دارید (User Token / Page Token). برای بسیاری از عملیات‌های Page باید Page Access Token داشته باشید.

4) Query Parameters (پارامترهای Query)

  • نوع داده: Key/Value
  • کاربرد: تعیین fields، limit، since/until، metric و…

پارامترهای رایج Graph API

  • access_token (String): توکن دسترسی

    مثال: EAABsbCS1iHgBA…

  • fields (String): انتخاب فیلدهای خروجی برای کم‌حجم کردن پاسخ

    مثال: id,name,fan_count

  • limit (Number): تعداد آیتم در pagination

    مثال: 25

  • since (String/Unix timestamp): شروع بازه زمانی

    مثال: 2025-01-01 یا 1735689600

  • until (String/Unix timestamp): پایان بازه زمانی

    مثال: 2025-01-31

  • metric (String): نام متریک‌ها برای insights

    مثال: page_impressions,page_engaged_users

  • period (String): دوره تجمیع متریک (day/week/days_28 و…)

    مثال: day

5) Headers (هدرها)

  • نوع داده: Key/Value
  • کاربرد: معمولاً برای Authorization یا Content-Type
  • مثال عملی: Authorization: Bearer <token>

نکته: بسیاری از endpointها access_token را در Query هم می‌پذیرند؛ اما ارسال توکن در Header معمولاً تمیزتر و امن‌تر است (به‌خصوص هنگام لاگ‌گیری).

6) Body (بدنه درخواست) برای POST

  • نوع داده: JSON یا Form-Encoded (بسته به endpoint)
  • کاربرد: ارسال پیام پست، لینک، رسانه و…
  • مثال عملی: ایجاد پست در Page با فیلد message

7) Response Format و Options در HTTP Request

  • نوع داده: تنظیمات نود
  • کاربرد: تعیین JSON بودن پاسخ، مدیریت خطاها، دنبال کردن ریدایرکت، Timeout و…

نکته مهم: گزینه‌هایی مثل “Ignore Response Code” را فقط وقتی فعال کنید که خودتان مدیریت خطا را انجام می‌دهید؛ در غیر این صورت عیب‌یابی سخت می‌شود.

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

ورودی‌های (Input) نود

در N8N، نود HTTP Request می‌تواند پارامترها را از آیتم ورودی بگیرد. رایج‌ترین ورودی‌ها:

  • pageId، postId، igUserId
  • accessToken (User/Page)
  • بازه زمانی since/until
  • متن/لینک پست برای انتشار

خروجی‌های (Output) نود

خروجی معمولاً JSON استاندارد Graph API است. چند نمونه متداول:

نمونه خروجی: خواندن اطلاعات یک Page

درخواست نمونه:

GET https://graph.facebook.com/v20.0/{page-id}?fields=id,name,fan_count

خروجی نمونه:

{  "id": "1234567890",  "name": "My Business Page",  "fan_count": 4210}

نمونه خروجی: Insights

GET https://graph.facebook.com/v20.0/{page-id}/insights?metric=page_impressions&period=day

{  "data": [    {      "name": "page_impressions",      "period": "day",      "values": [        { "value": 1532, "end_time": "2025-01-27T08:00:00+0000" },        { "value": 1710, "end_time": "2025-01-28T08:00:00+0000" }      ],      "title": "Daily Total Impressions",      "description": "Daily: The number of times any content from your Page..."    }  ],  "paging": {    "previous": "https://graph.facebook.com/...",    "next": "https://graph.facebook.com/..."  }}

نمونه خروجی: انتشار پست

POST https://graph.facebook.com/v20.0/{page-id}/feed

{  "id": "1234567890_9988776655"}

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

1) استفاده از fields برای کاهش حجم پاسخ و افزایش سرعت

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

2) مدیریت Pagination به شکل استاندارد

بسیاری از پاسخ‌ها paging.next دارند. یک الگوی رایج در N8N:

  • HTTP Request (صفحه اول)
  • IF: آیا paging.next وجود دارد؟
  • Loop (مثلاً با Split in Batches یا تکرار با Code node) برای فراخوانی paging.next تا پایان

ترفند: اگر از n8n نسخه‌های جدید استفاده می‌کنید، می‌توانید با ترکیب Code و HTTP Request، لینک next را دینامیک تنظیم کنید.

3) ساخت Page Access Token از روی User Token (الگوی عملی)

برای بسیاری از عملیات‌های مدیریتی Page، باید Page Token داشته باشید. الگوی رایج:

  • گرفتن User Access Token با OAuth2
  • درخواست GET به /me/accounts برای دریافت لیست Pageها و access_token مربوطه
  • ذخیره کردن page access_token در Data Store یا یک جدول امن (ترجیحاً کوتاه‌مدت)

4) جلوگیری از ریت‌لیمیت با زمان‌بندی و Batch کردن

  • برای خواندن اطلاعات چند Page یا چند Post، درخواست‌ها را پشت سر هم و با تاخیر کوتاه اجرا کنید (مثلاً Wait node بین درخواست‌ها).
  • از limit منطقی استفاده کنید و بازه‌های زمانی را خرد کنید (مثلاً روزانه به‌جای ماهانه) تا پاسخ‌ها کوچک‌تر باشند.

5) ثبت لاگ قابل عیب‌یابی

در کنار خروجی خام API، بهتر است این موارد را ثبت کنید:

  • endpoint و query مهم (بدون ذخیره access_token در لاگ)
  • status code
  • error.message و error.code در صورت خطا

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

محدودیت‌ها

  • نیاز به دسترسی‌ها (Permissions): بسیاری از endpointها نیازمند permissionهای خاص هستند و بدون آن‌ها خطای دسترسی می‌گیرید.
  • توکن‌های کوتاه‌عمر/بلندعمر: بعضی توکن‌ها منقضی می‌شوند و باید تمدید یا بازتولید شوند.
  • تغییرات نسخه API: با تغییر نسخه Graph ممکن است برخی فیلدها حذف یا رفتارشان تغییر کند.
  • محدودیت داده: برخی insights یا داده‌ها فقط برای بازه زمانی مشخص یا برای نوع خاصی از اکانت‌ها در دسترس است.

خطاهای رایج و راه‌حل‌ها

  • خطا: (#200) Permissions error

    علت: permission لازم را ندارید یا ادمین/نقش مناسب روی Page ندارید.

    راه‌حل: بررسی scopes در OAuth، بررسی نقش کاربر در Page، و اطمینان از استفاده از Page Access Token در عملیات‌های Page.

  • خطا: Invalid OAuth access token

    علت: توکن اشتباه/منقضی/کپی ناقص

    راه‌حل: تولید مجدد توکن، بررسی زمان انقضا، و اطمینان از اینکه توکن مربوط به همان اپ و همان محیط است.

  • خطا: Unsupported get request

    علت: ID اشتباه است، به آن resource دسترسی ندارید، یا endpoint درست نیست.

    راه‌حل: بررسی page-id/post-id، تست endpoint با Graph API Explorer، و افزودن fields معتبر.

  • خطا: Rate limit / Application request limit reached

    علت: تعداد درخواست‌ها زیاد شده است.

    راه‌حل: کاهش دفعات اجرا، استفاده از caching، batch کردن، و افزودن Wait بین درخواست‌ها.

  • خطاهای داده‌ای در Insights (خروجی خالی)

    علت: متریک/period نامعتبر، یا بازه زمانی داده ندارد.

    راه‌حل: بررسی نام metric، استفاده از period صحیح، و تست با بازه کوتاه‌تر.

ایده ها

  • سیستم گزارش‌گیری هفتگی KPI شبکه‌های اجتماعی: خواندن Insights و ارسال خلاصه به Slack یا ایمیل.
  • هشدار افت تعامل: اگر reach یا engaged_users نسبت به میانگین ۷ روزه افت کرد، اعلان خودکار ارسال شود.
  • اتوماسیون پاسخ‌گویی اولیه به کامنت‌ها: شناسایی کلمات کلیدی و ارسال پاسخ استاندارد یا ساخت تیکت.
  • تقویم انتشار محتوا: خواندن پست‌های زمان‌بندی‌شده از Notion و انتشار خودکار در Page.
  • آرشیو پست‌ها و آمار: ذخیره لینک پست، متن، زمان انتشار و آمار اولیه در Google Sheets برای تحلیل‌های بعدی.

منابع و مستندات اصلی

دسته بندی: N8N برچسب ها:

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

3 × دو =