تطوير n8n Community Node لمنصة Whats360: دليل بناء التكامل الرسمي لأتمتة واتساب والرسائل والحملات والذكاء الاصطناعي

أصبحت منصات الأتمتة المرئية مثل n8n جزءًا أساسيًا من البنية التقنية للشركات التي تريد ربط الأنظمة المختلفة دون بناء تكاملات HTTP منفصلة لكل عملية. وفي هذا السياق يأتي تطوير Whats360 Community Node ليحوّل التكامل مع واتساب والرسائل النصية والحملات والبريد الإلكتروني إلى تجربة مباشرة داخل Workflow واحد.

الفكرة الأساسية ليست مجرد إنشاء Node يرسل رسالة واتساب، وإنما بناء طبقة تكامل منظمة تجعل خدمات Whats360 قابلة للاستخدام من المطورين، أصحاب المتاجر، فرق المبيعات، مهندسي الأنظمة، ومطوري وكلاء الذكاء الاصطناعي من داخل n8n، مع تقليل الحاجة إلى كتابة HTTP Requests يدويًا أو التعامل المباشر مع معرفات الأجهزة وصيغ أرقام الهاتف.

ويعتمد التصميم المقترح على مجموعة من الموارد والعمليات التي تغطي الرسائل، وإدارة Instances، والحملات، وSMS وUSSD عبر VCash، والبريد الإلكتروني، بالإضافة إلى Trigger لاستقبال Webhooks من Whats360.

لماذا تحتاج Whats360 إلى Community Node داخل n8n؟

القيمة الحقيقية في هذا المشروع تظهر عندما ننظر إلى طريقة بناء الأتمتة الحديثة. المستخدم الذي يريد ربط متجر إلكتروني مع واتساب يمكنه تنفيذ ذلك عبر HTTP Request، لكن هذا الأسلوب يجعله مسؤولًا عن تفاصيل كثيرة: معرفة عنوان API، اختيار HTTP Method الصحيح، إضافة Token، تجهيز JID، بناء Query Parameters، التعامل مع الاستجابات، ومعالجة الأخطاء.

وجود Node متخصص يلغي جزءًا كبيرًا من هذا التعقيد. المستخدم يرى عملية مثل Send Text بدلًا من Endpoint مثل /api/v1/send-text، ويختار Instance من قائمة ديناميكية بدلًا من نسخ Instance ID يدويًا، ويكتب رقم الهاتف بصيغته المعتادة بدلًا من تحويله بنفسه إلى WhatsApp JID.

وهذا يجعل Node مناسبًا لفئة واسعة من المستخدمين. المطور يستطيع استخدامه داخل Workflow برمجي، وصاحب المتجر يستطيع استخدامه مع Trigger خاص بالطلبات، ومدير المبيعات يستطيع بناء سيناريوهات متابعة العملاء، بينما يستطيع مطور AI Agent استخدامه كأداة لإرسال الردود إلى العملاء.

لذلك فإن الرؤية لا تقوم على بناء Wrapper بسيط للـ API، وإنما على إنشاء طبقة استخدام عملية فوق خدمات Whats360.

الرؤية العامة للمنتج

الحزمة المقترحة تحمل اسم n8n-nodes-whats360، وهدفها أن تصبح إضافة Community Node متخصصة تسمح بدمج خدمات Whats360 داخل مسارات العمل في n8n.

المنتج يستهدف الشركات والمطورين ومطوري أنظمة CRM ومهندسي التكامل ومطوري وكلاء الذكاء الاصطناعي، مع التركيز على إزالة العمليات اليدوية المتكررة.

تكامل بدون كتابة HTTP يدويًا

أحد أهم أهداف Node هو تقديم Zero-Code Integration. بدلًا من بناء HTTP Request لكل عملية، يتم تقديم واجهة تحتوي على Resource ثم Operation ثم الحقول الخاصة بالعملية.

فعلى سبيل المثال، عندما يريد المستخدم إرسال صورة، يختار Message ثم Send Image، وبعد ذلك يحدد Instance ورقم المستلم ورابط الصورة والكابشن. يقوم Node بتحويل هذه القيم إلى الطلب المناسب تلقائيًا.

جاهزية وكلاء الذكاء الاصطناعي

وجود Node مخصص للرسائل يجعل Whats360 مناسبًا أيضًا لسيناريوهات AI Agents. يمكن استقبال الرسالة عبر Trigger، تمرير محتواها إلى Agent، ثم استخدام Node لإرسال الإجابة الناتجة إلى العميل.

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

التعامل الذكي مع أرقام الهاتف

من المشاكل المتكررة في تكاملات واتساب اختلاف صيغة رقم الهاتف. قد يصل الرقم بصيغة +201234567890، أو 201234567890، أو 00201234567890، أو قد يكون أصلًا JID.

الدالة formatToJid() تتولى تحويل الرقم إلى الصيغة المطلوبة، مثل:

201234567890@s.whatsapp.net

كما أنها تحافظ على JID إذا كان المستخدم قد مرره بالفعل بصيغة @s.whatsapp.net أو @g.us.

تشخيص الأخطاء بدلًا من عرض رسائل غامضة

لا يكفي أن يعرف المستخدم أن HTTP Request فشل. في سيناريوهات الأتمتة، يحتاج المستخدم إلى معرفة السبب وما الذي يمكن فعله بعد ذلك.

لذلك يحتوي التصميم على طبقة معالجة للأخطاء تربط بعض أكواد الاستجابة برسائل مفهومة. فعند ظهور الخطأ 463 يتم تقديم تفسير خاص بسياق جلسة المحادثة، بينما يتم توضيح أخطاء المصادقة 401 وأخطاء عدم العثور على Instance أو Device عند 404، وكذلك حالات تجاوز حدود الخطة عند 403.

خريطة العمليات المدعومة

تم تقسيم وظائف Node إلى موارد واضحة. هذا التقسيم يجعل واجهة n8n أسهل في الاستخدام، ويسمح بإضافة عمليات مستقبلية دون تحويل العقدة إلى قائمة ضخمة غير منظمة.

المورد	العملية	HTTP Method	Endpoint
Message	Send Text	GET	/api/v1/send-text
Message	Send Image	GET	/api/v1/send-image
Message	Send Video	GET	/api/v1/send-video
Message	Send Audio	GET	/api/v1/send-audio
Message	Send Document	GET	/api/v1/send-doc
Instance	List / Create / Connect / Disconnect / Status / QR / Delete	GET	/api/v1/instances/*
Campaign	List / Create / Recipients / Start / Pause / Resume / Stop / Status / Delete	GET / POST	/api/v1/campaigns/*
VCash	SMS / Devices / USSD / Balance / Transactions	GET / POST	/api/v1/vcash/*
Email	Send Email	POST	/api/v1/email/send
Trigger	Incoming Webhook	POST	Webhook URL

رسائل واتساب داخل Workflow

قسم Message هو نقطة الاستخدام الأكثر مباشرة في الحزمة. فهو يوفر عمليات إرسال النصوص والصور والفيديو والصوت والمستندات.

إرسال رسالة نصية

عملية Send Text تعتمد على Instance ID وJID ونص الرسالة. يقوم Node بتحويل رقم المستلم إلى JID ثم يرسل الطلب إلى:

/api/v1/send-text

وتكون المعاملات الأساسية هي Token وInstance ID وJID وMessage.

هذه العملية مناسبة لعدد كبير من سيناريوهات الأتمتة؛ مثل إرسال تأكيد الطلب، تنبيه فريق المبيعات، إرسال إشعار بعد تغيير حالة الطلب، أو الرد على عميل بعد معالجة رسالة واردة.

إرسال الصور

عملية Send Image تستقبل رابطًا عامًا مباشرًا للصورة، بالإضافة إلى Caption اختياري.

يتم تمرير البيانات إلى Endpoint:

/api/v1/send-image

وتستخدم الحقول instance_id وjid وimageurl وcaption.

إرسال الفيديو والصوت والمستندات

نفس الفكرة تمتد إلى الفيديو والصوت والمستندات. يتم اختيار العملية من واجهة Node، ثم تظهر الحقول المناسبة فقط باستخدام displayOptions.

إرسال الفيديو يستخدم videoUrl والكابشن، بينما إرسال الصوت يعتمد على audioUrl. أما المستند فيستخدم docUrl مع Caption اختياري.

هذه الطريقة تمنع ازدحام الواجهة، لأن المستخدم لا يرى الحقول التي لا علاقة لها بالعملية التي اختارها.

إدارة Instances والأجهزة

لا تقتصر الحزمة على إرسال الرسائل. فهي تتعامل أيضًا مع دورة حياة Instance من داخل n8n.

يوفر Resource الخاص بالـ Instance عمليات الحصول على جميع Instances، إنشاء Instance جديد، معرفة الحالة، الحصول على QR Code، الاتصال، قطع الاتصال، وحذف Instance.

القائمة الديناميكية للأجهزة

من أهم التفاصيل في تجربة الاستخدام وجود loadOptionsMethod باسم getInstances. عند فتح قائمة الأجهزة داخل Node، يتم استدعاء:

GET /api/v1/instances

ثم يتم تحويل النتيجة إلى خيارات مناسبة لواجهة n8n.

يتم عرض اسم Instance مع الحالة، بينما تكون القيمة الفعلية هي المعرف الذي يحتاجه API.

هذا التصميم يزيل خطوة نسخ المعرفات يدويًا، كما يسمح باستخدام Expressions عند الحاجة إلى قيمة ديناميكية.

إنشاء Instance

عملية إنشاء Instance تستقبل معرفًا جديدًا واسمًا وصفيًا، ثم ترسلها إلى Endpoint:

/api/v1/instances/create

وبعد الإنشاء يمكن استخدام عمليات الاتصال والحصول على الحالة وQR Code من داخل Workflow نفسه.

مراقبة حالة الاتصال

يمكن استخدام Get Status في Workflow لمراقبة حالة الجهاز أو اتخاذ قرار بناءً على حالة الاتصال، بدلًا من تنفيذ فحص منفصل خارج n8n.

إدارة الحملات من خلال n8n

Resource الخاص بالحملات يضيف طبقة أتمتة مهمة، لأنه يسمح بإنشاء Campaign ثم إضافة المستلمين والتحكم في دورة تشغيلها.

تشمل العمليات المتاحة إنشاء الحملة، إضافة المستلمين، بدء الحملة، إيقافها مؤقتًا، استئنافها، إيقافها، معرفة حالتها، وحذفها.

إنشاء حملة

عملية Create Campaign تستقبل اسم الحملة ومحتوى الرسالة، ثم ترسل البيانات إلى:

POST /api/v1/campaigns/create

ويتم تمرير instance_id مع Body يحتوي على name وmessage_content.

إضافة المستلمين

عملية Add Recipients تعتمد على Campaign ID وبيانات المستلمين بصيغة JSON. ويتيح ذلك تمرير قائمة تحتوي على رقم الهاتف والاسم والمتغيرات المخصصة التي يحتاجها نظام الحملة.

[
  {
    "phone": "201234567890",
    "name": "Ahmed"
  }
]

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

التحكم في دورة الحملة

بعد إنشاء الحملة وإضافة المستلمين، يمكن تشغيلها أو إيقافها مؤقتًا أو استئنافها أو إيقافها نهائيًا. كما يمكن طلب حالة الحملة باستخدام Campaign Status.

وهذا يفتح الباب أمام Workflows تعتمد على حالة الحملة لاتخاذ إجراءات لاحقة تلقائيًا.

تكامل SMS وUSSD عبر VCash

توسع الحزمة مفهوم الاتصال من واتساب إلى SMS وUSSD من خلال Resource خاص بـ VCash.

تتضمن العمليات Send SMS وList VCash Devices وExecute USSD وGet Wallet Balance وGet Transactions.

إرسال SMS

عملية Send SMS تعتمد على Device ID ورقم المستلم ونص الرسالة وSIM Slot.

POST /api/v1/vcash/sms/send

ويتم إرسال البيانات داخل Body:

{
  "device_id": "abc123",
  "recipient": "01012345678",
  "message": "رسالة تجريبية",
  "sim_slot": 1
}

تنفيذ USSD

يوفر Node أيضًا عملية Execute USSD، وهي تعتمد على Device ID والأمر وSIM Slot، وتستخدم Endpoint:

POST /api/v1/vcash/ussd/execute

وبذلك يمكن بناء Workflow يتعامل مع الجهاز المتصل وينفذ أمر USSD من خلال المسار الآلي.

الرصيد والمعاملات

يمكن كذلك استدعاء بيانات الرصيد والمعاملات من خلال Get Wallet Balance وGet Transactions، ما يسمح بإدخال هذه المعلومات ضمن مسارات العمل التي تحتاج إلى مراقبة البيانات المالية أو التشغيلية.

إرسال البريد الإلكتروني

يضم Node أيضًا Resource خاصًا بالبريد الإلكتروني، ويقدم عملية Send Email.

تعتمد العملية على عنوان المرسل والمستلم وSubject وBody، ويتم إرسالها عبر:

POST /api/v1/email/send

وهذا يسمح ببناء Workflow متعدد القنوات، بحيث لا يتوقف السيناريو عند واتساب فقط، وإنما يستطيع إرسال البريد الإلكتروني ضمن نفس سلسلة الأتمتة.

تصميم Credentials بطريقة موحدة

تم تصميم الاعتماد باسم whats360Api ويحتوي على عنصرين رئيسيين: Base URL وAPI Token.

القيمة الافتراضية للـ Base URL هي:

https://whats360.live

مع إمكانية تغييرها عند استخدام Self-Hosted أو Private Instance.

أما API Token فيتم تخزينه كحقل Password حتى لا يظهر بصورة مكشوفة في واجهة المستخدم.

بعد الحصول على Credentials يستخدم Helper موحد البيانات في جميع الطلبات، ويضيف Token إلى Query Parameter، بالإضافة إلى Bearer Authorization Header.

الطبقة المركزية للاتصال بالـ API

وجود دالة واحدة مثل whats360ApiRequest() يمثل جزءًا مهمًا من التصميم. بدل تكرار كود المصادقة ومعالجة الأخطاء في كل عملية، يتم وضع المنطق المشترك في Helper واحد.

الدالة تستقبل HTTP Method وEndpoint وBody وQuery Parameters، ثم تبني الطلب النهائي.

export async function whats360ApiRequest(
  this: IExecuteFunctions | ILoadOptionsFunctions | IHookFunctions,
  method: IHttpRequestMethods,
  endpoint: string,
  body: IDataObject = {},
  qs: IDataObject = {},
): Promise<any> {
  const credentials = await this.getCredentials('whats360Api');

  const baseUrl =
    ((credentials.baseUrl as string) || 'https://whats360.live')
      .replace(/\/$/, '');

  const token = credentials.apiToken as string;

  const query: IDataObject = {
    token,
    ...qs,
  };

  const options: IHttpRequestOptions = {
    method,
    url: `${baseUrl}${endpoint}`,
    headers: {
      'Accept': 'application/json',
      'Authorization': `Bearer ${token}`,
    },
    qs: query,
    json: true,
  };

  if (method === 'POST' || method === 'PUT') {
    options.body = body;
  }

  return await this.helpers.httpRequest(options);
}

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

المعالجة الذكية للأخطاء

التعامل مع الأخطاء ليس تفصيلًا ثانويًا في Node مخصص للأتمتة. أي خطأ غير مفهوم يمكن أن يؤدي إلى توقف Workflow أو إلى إهدار وقت المطور في البحث عن سبب المشكلة.

لذلك يتم تحليل statusCode والاستجابة القادمة من API ثم تحويل بعض الحالات المعروفة إلى رسائل أكثر وضوحًا.

خطأ المصادقة

عند الحصول على 401، تظهر رسالة توضّح أن API Token غير صالح أو منتهي، مع توجيه المستخدم لمراجعة Credentials الخاصة بـ Whats360.

خطأ عدم العثور على Instance أو Device

عند ظهور 404 يتم توضيح أن Instance أو Device المحدد غير موجود ضمن الحساب المستخدم.

تجاوز الحدود

عند ظهور 403 يتم توضيح أن حد الخطة الخاص بالرسائل أو Instances قد تم الوصول إليه.

خطأ WhatsApp 463

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

هيكل المشروع البرمجي

تم تقسيم المشروع إلى أجزاء مستقلة للحفاظ على قابلية الصيانة والتوسع.

n8n-nodes-whats360/
├── package.json
├── tsconfig.json
├── .eslintrc.js
├── .gitignore
├── README.md
├── LICENSE
├── assets/
│   ├── whats360.png
│   └── whats360.svg
├── credentials/
│   └── Whats360Api.credentials.ts
└── nodes/
    ├── Whats360/
    │   ├── Whats360.node.json
    │   ├── Whats360.node.ts
    │   ├── GenericFunctions.ts
    │   └── descriptions/
    │       ├── MessageDescription.ts
    │       ├── InstanceDescription.ts
    │       ├── CampaignDescription.ts
    │       ├── VcashDescription.ts
    │       └── EmailDescription.ts
    └── Whats360Trigger/
        ├── Whats360Trigger.node.json
        └── Whats360Trigger.node.ts

هذا التقسيم يفصل منطق الاتصال عن تعريف الحقول وعن منطق التنفيذ الرئيسي. كما يجعل إضافة Resource جديد أكثر تنظيمًا.

العقدة الرئيسية Whats360

العقدة الرئيسية تحمل الاسم Whats360 وتقدم Resources متعددة داخل واجهة واحدة.

الموارد الأساسية هي Message وInstance وCampaign وSMS & USSD وEmail.

ويتم تحديد العملية من خلال الحقل operation، ثم يقرأ التنفيذ القيم الخاصة بكل عملية ويرسل الطلب المناسب.

هذا الأسلوب يحافظ على تجربة موحدة للمستخدم: نفس Credentials، ونفس Node، مع اختلاف Resource وOperation حسب الهدف.

عقدة Whats360 Trigger

لا تكتمل منظومة الأتمتة بمجرد إرسال الرسائل. يجب أن يكون هناك طريق عكسي تستقبل من خلاله الأحداث الواردة من Whats360.

لهذا السبب تحتوي الحزمة على عقدة مستقلة باسم Whats360 Trigger.

هذه العقدة تستقبل POST Webhook، ويمكنها التعامل مع أحداث مثل الرسائل الواردة، الرسائل الصادرة، فشل الإرسال، وانتهاء الاشتراك.

توحيد بيانات الـ Webhook

قد تختلف أسماء الحقول القادمة من المصدر، ولذلك يقوم Trigger بتوحيدها في Payload واضح.

{
  "sender_phone": "",
  "sender_name": "",
  "message": "",
  "message_id": "",
  "chat_jid": "",
  "instance_id": "",
  "timestamp": 0,
  "media_url": null,
  "raw": {}
}

وجود الحقل raw مهم لأنه يحافظ على البيانات الأصلية القادمة من Webhook، بينما تمنح الحقول الموحدة العقد التالية في Workflow واجهة ثابتة للتعامل مع البيانات.

حماية Webhook

يتضمن التصميم Secret Header اختياريًا. عند تفعيله، تتم مقارنة القيمة القادمة في X-Hook-Secret أو X-Secret-Key بالقيمة التي تم إعدادها داخل Node.

إذا لم تتطابق القيمة، يتم رفض الطلب برسالة Unauthorized.

بناء وكيل ذكاء اصطناعي عبر واتساب

من أقوى السيناريوهات المقترحة استخدام Trigger لاستقبال رسالة العميل ثم تمريرها إلى AI Agent أو LangChain Node، وبعد إنتاج الإجابة يتم إرسالها مرة أخرى إلى العميل باستخدام عملية Send Text.

التدفق المنطقي يكون:

[Whats360 Trigger]
       ↓
[AI Agent / LangChain]
       ↓
[Whats360 - Send Text]
       ↓
[Customer WhatsApp]

ويستفيد هذا السيناريو من خاصية توحيد رقم المرسل. فإذا وصل sender_phone من Webhook، يمكن تمريره إلى Node، ليتم تحويله إلى JID عند الإرسال.

بهذا يصبح Whats360 قناة اتصال للوكيل، بينما يتولى n8n إدارة منطق الـ Workflow والأدوات والربط بين الخدمات.

ويظهر هنا جانب مهم من تصميم العقدة، وهو أنها لا تقتصر على إرسال الرسائل فقط، بل تجعل Whats360 جزءًا من بنية الأتمتة نفسها. ويمكن استخدام نفس الفكرة لبناء وكلاء مبيعات، ووكلاء دعم فني، وأنظمة متابعة تلقائية للعملاء.

أتمتة إشعارات المتاجر الإلكترونية عبر WhatsApp

من أكثر الاستخدامات العملية للعقدة ربط المتاجر الإلكترونية مع WhatsApp. فعند إنشاء طلب جديد في WooCommerce أو Shopify يمكن لـ n8n استقبال بيانات الطلب، تجهيز رسالة مناسبة، ثم تمرير رقم العميل إلى عقدة Whats360 لإرسال الإشعار تلقائيًا.

يمكن أن يبدأ مسار العمل من Trigger خاص بالمتجر، ثم تمر بيانات الطلب إلى عقدة Code أو Set لاستخراج رقم الهاتف واسم العميل وقيمة الطلب والمنتجات، وبعد ذلك يتم إرسال الرسالة إلى العميل من خلال Whats360.

[WooCommerce Trigger]
       ↓
[Code / Set Node]
       ↓
[Extract Customer Phone]
       ↓
[Whats360 - Send Text]
       ↓
[Customer WhatsApp]

وهذا النوع من التكامل مناسب بشكل خاص للمتاجر التي تحتاج إلى إرسال تأكيد الطلب، وتحديثات حالة الطلب، وإشعارات الشحن أو المتابعة دون تدخل يدوي.

كما يمكن استخدام نفس البنية مع Toggaar أو أي منصة تجارة إلكترونية توفر Trigger أو Webhook يمكن لـ n8n التعامل معه.

تحويل العملاء المحتملين إلى فريق المبيعات

لا تقتصر استخدامات العقدة على المتاجر. يمكن كذلك بناء مسار عمل يبدأ من نماذج الإعلانات أو مصادر Leads، ثم يرسل رسالة ترحيبية إلى العميل المحتمل على WhatsApp، وفي الوقت نفسه يرسل تنبيهًا إلى موظف المبيعات.

على سبيل المثال، يمكن استقبال Lead جديد من Facebook Lead Ads، ثم استخدام بيانات العميل لإنشاء رسالة شخصية، وإرسالها من خلال Whats360.

بعد ذلك يمكن استخدام VCash لإرسال رسالة SMS إلى مندوب المبيعات أو الموظف المسؤول عن متابعة العميل، إذا كان هذا السيناريو جزءًا من البنية التشغيلية للمشروع.

[Facebook Lead Ads Trigger]
       ↓
[Extract Lead Data]
       ↓
[Whats360 - Send WhatsApp]
       ↓
[VCash - Send SMS]
       ↓
[Sales Representative]

الميزة هنا أن n8n يعمل كطبقة Orchestration بين الخدمات، بينما تتولى كل خدمة تنفيذ الجزء الخاص بها من العملية.

لماذا Dynamic Dropdowns مهمة في عقدة Whats360؟

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

لهذا تعتمد العقدة المقترحة على loadOptionsMethod لجلب الأجهزة من Endpoint الخاص بالـ Instances.

async getInstances(this: ILoadOptionsFunctions): Promise<INodePropertyOptions[]> {
	try {
		const response = await whats360ApiRequest.call(
			this,
			'GET',
			'/api/v1/instances',
		);

		const returnData: INodePropertyOptions[] = [];
		const instances =
			response.response ||
			response.data ||
			response.instances ||
			[];

		if (Array.isArray(instances)) {
			for (const inst of instances) {
				returnData.push({
					name: `${inst.name || inst.id} (${inst.status || 'active'})`,
					value: inst.id || inst.instance_id,
				});
			}
		}

		return returnData;
	} catch (error) {
		return [];
	}
}

وبذلك تظهر الأجهزة المتاحة في قائمة داخل واجهة n8n بدل مطالبة المستخدم بنسخ Instance ID ولصقه يدويًا.

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

توحيد أرقام WhatsApp باستخدام Smart JID Formatting

إرسال رسالة WhatsApp من خلال API يحتاج إلى صيغة مناسبة للمستلم. ولذلك تحتوي العقدة على وظيفة formatToJid تقوم بتحويل رقم الهاتف إلى JID مناسب قبل تنفيذ عملية الإرسال.

يمكن للمستخدم إدخال الرقم بصيغة دولية تبدأ بعلامة +، أو بصيغة تحتوي على 00، أو إدخال JID جاهز.

export function formatToJid(recipient: string): string {
	if (!recipient) {
		throw new NodeOperationError(
			{} as any,
			'Recipient phone number or JID cannot be empty.',
		);
	}

	let cleaned = recipient.trim();

	if (
		cleaned.includes('@s.whatsapp.net') ||
		cleaned.includes('@g.us')
	) {
		return cleaned;
	}

	cleaned = cleaned.replace(/[^\d]/g, '');

	if (cleaned.startsWith('00')) {
		cleaned = cleaned.substring(2);
	}

	return `${cleaned}@s.whatsapp.net`;
}

فعلى سبيل المثال يمكن تمرير رقم مثل +201234567890 أو 00201234567890، ثم تقوم الوظيفة بتجهيزه بالشكل الذي تحتاجه عملية الإرسال.

التعامل مع أخطاء API بطريقة قابلة للتنفيذ

إظهار رسالة HTTP عامة مثل 404 أو 403 لا يساعد دائمًا المستخدم في معرفة ما يجب فعله. لذلك تحتوي طبقة الاتصال المقترحة على معالجة مخصصة لبعض الأخطاء المتوقعة.

تبدأ الوظيفة بجلب بيانات Credentials، ثم تجهيز Base URL وToken، وبعدها بناء طلب HTTP موحد يمكن استخدامه مع مختلف موارد Whats360.

export async function whats360ApiRequest(
	this: IExecuteFunctions | ILoadOptionsFunctions | IHookFunctions,
	method: IHttpRequestMethods,
	endpoint: string,
	body: IDataObject = {},
	qs: IDataObject = {},
): Promise<any> {
	const credentials = await this.getCredentials('whats360Api');

	const baseUrl =
		((credentials.baseUrl as string) || 'https://whats360.live')
			.replace(/\/$/, '');

	const token = credentials.apiToken as string;

	const query: IDataObject = {
		token,
		...qs,
	};

	const options: IHttpRequestOptions = {
		method,
		url: `${baseUrl}${endpoint}`,
		headers: {
			'Accept': 'application/json',
			'Authorization': `Bearer ${token}`,
		},
		qs: query,
		json: true,
	};

	if (method === 'POST' || method === 'PUT') {
		options.body = body;
	}

	try {
		return await this.helpers.httpRequest(options);
	} catch (error: any) {
		const statusCode =
			error.statusCode ||
			error.response?.status;

		const errorResponse =
			error.response?.data ||
			error.cause?.response?.data;

		let customMessage =
			errorResponse?.error ||
			errorResponse?.message ||
			error.message;

		throw new NodeApiError(
			this.getNode(),
			error,
			{
				message: customMessage,
				httpCode: statusCode
					? `${statusCode}`
					: undefined,
			},
		);
	}
}

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

خطأ 463

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

if (statusCode === 463) {
	customMessage =
		'WhatsApp Error [463]: The recipient has not opened a conversation window yet, or encryption is uninitialized. Solution: Send a direct message from the phone to this number first to initiate the session.';
}

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

أخطاء المصادقة والموارد والحدود

يمكن تطبيق الأسلوب نفسه على أخطاء المصادقة، والموارد غير الموجودة، وحدود الحساب.

if (statusCode === 401) {
	customMessage =
		'Authentication Error [401]: The API Token provided is invalid or expired. Check your Whats360 credentials.';
} else if (statusCode === 404) {
	customMessage =
		'Not Found [404]: The specified Instance or Device ID was not found on your Whats360 account.';
} else if (statusCode === 403) {
	customMessage =
		'Limit Exceeded [403]: Your account plan limit for messages or instances has been reached.';
}

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

إدارة Instances وأجهزة WhatsApp من داخل n8n

لا تعمل العقدة كوسيلة لإرسال الرسائل فقط، بل توفر طبقة لإدارة Instances المرتبطة بالحساب.

يمكن من خلالها استدعاء عمليات الحصول على جميع Instances، وإنشاء Instance جديد، ومعرفة حالة الاتصال، والحصول على QR Code، والاتصال، وقطع الاتصال، وحذف Instance.

العملية	Endpoint	الاستخدام
Get All Instances	/api/v1/instances	عرض الأجهزة المسجلة
Create Instance	/api/v1/instances/create	إنشاء Instance جديد
Get Status	/api/v1/instances/status	معرفة حالة الاتصال
Get QR Code	/api/v1/instances/qr	الحصول على QR Code
Connect Instance	/api/v1/instances/connect	بدء جلسة الاتصال
Disconnect Instance	/api/v1/instances/disconnect	قطع الاتصال
Delete Instance	/api/v1/instances/delete	حذف Instance

وجود هذه العمليات داخل Node واحدة يجعل n8n قادرًا على التعامل مع دورة حياة الجهاز ضمن Workflow، وليس فقط تنفيذ عملية إرسال منفردة.

أتمتة الحملات التسويقية

يدعم التصميم المقترح أيضًا موارد Campaigns، بما يسمح بإدارة الحملات من داخل مسارات عمل n8n.

يمكن إنشاء حملة، إضافة المستلمين، تشغيل الحملة أو إيقافها مؤقتًا، استئنافها، إيقافها، معرفة حالتها، أو حذفها.

[Trigger]
       ↓
[Prepare Campaign Data]
       ↓
[Whats360 - Create Campaign]
       ↓
[Whats360 - Add Recipients]
       ↓
[Whats360 - Start Campaign]
       ↓
[Whats360 - Campaign Status]

ويصبح هذا مفيدًا عندما تكون قائمة المستلمين أو محتوى الحملة ناتجًا عن Workflow آخر، مثل بيانات CRM أو نتائج نموذج أو عملية تجميع Leads.

كما يمكن تمرير بيانات المستلمين بصيغة JSON، وهو ما يتيح استخدام المتغيرات المخصصة داخل بنية الحملة.

[
	{
		"phone": "201234567890",
		"name": "Ahmed"
	}
]

وبهذه الطريقة يمكن أن تكون بيانات الحملة جزءًا من عملية أتمتة أكبر بدل إدخالها يدويًا في لوحة مستقلة.

تكامل SMS وUSSD من خلال VCash

تمتد الحزمة المقترحة إلى ما هو أبعد من WhatsApp من خلال دعم عمليات VCash، بما في ذلك إرسال SMS، وعرض الأجهزة، وتنفيذ USSD، والحصول على الرصيد، وقراءة المعاملات.

هذا يجعل n8n قادرًا على إنشاء Workflows متعددة القنوات يمكن أن تجمع بين WhatsApp وSMS وعمليات USSD داخل نفس المنطق التشغيلي.

المورد	العملية	Endpoint
VCash	Send SMS	/api/v1/vcash/sms/send
VCash	List Devices	/api/v1/vcash/devices
VCash	Execute USSD	/api/v1/vcash/ussd/execute
VCash	Get Balance	/api/v1/vcash/balance
VCash	Get Transactions	/api/v1/vcash/transactions

ومن الناحية العملية يمكن استخدام SMS كقناة احتياطية أو كقناة تنبيه داخلية، بينما تظل WhatsApp هي قناة التواصل الرئيسية مع العميل.

إرسال البريد الإلكتروني من نفس Workflow

يدعم التصميم كذلك إرسال البريد الإلكتروني من خلال Endpoint مخصص داخل Whats360.

responseData = await whats360ApiRequest.call(
	this,
	'POST',
	'/api/v1/email/send',
	{
		from,
		to,
		subject,
		body,
	},
);

وهذا يفتح المجال لبناء عمليات متعددة القنوات، مثل إرسال WhatsApp للعميل، ثم بريد إلكتروني يحتوي على تفاصيل إضافية، ثم تسجيل نتيجة العملية داخل CRM.

تصميم Credentials بشكل آمن ومرن

تعتمد الحزمة على Credential باسم whats360Api، ويحتوي على Base URL وAPI Token.

export class Whats360Api implements ICredentialType {
	name = 'whats360Api';
	displayName = 'Whats360 API';
	documentationUrl = 'https://whats360.live';

	properties: INodeProperties[] = [
		{
			displayName: 'Base URL',
			name: 'baseUrl',
			type: 'string',
			default: 'https://whats360.live',
			required: true,
			description: 'The base URL of the Whats360 API instance',
		},
		{
			displayName: 'API Token',
			name: 'apiToken',
			type: 'string',
			typeOptions: {
				password: true,
			},
			default: '',
			required: true,
			description:
				'Your Whats360 API Token from Developers Portal / Settings',
		},
	];
}

ويتيح وجود Base URL قابل للتعديل استخدام البنية نفسها مع بيئات مختلفة عند الحاجة، بينما يبقى الـ API Token محميًا داخل Credentials الخاصة بـ n8n بدل وضعه داخل كل Node أو Workflow.

هيكل مشروع n8n-nodes-whats360

تقسيم المشروع إلى ملفات واضحة يجعل تطوير الحزمة وصيانتها أسهل، خصوصًا مع زيادة عدد الموارد والعمليات في الإصدارات المستقبلية.

n8n-nodes-whats360/
├── package.json
├── tsconfig.json
├── .eslintrc.js
├── .gitignore
├── README.md
├── LICENSE
├── assets/
│   ├── whats360.png
│   └── whats360.svg
├── credentials/
│   └── Whats360Api.credentials.ts
└── nodes/
    ├── Whats360/
    │   ├── Whats360.node.json
    │   ├── Whats360.node.ts
    │   ├── GenericFunctions.ts
    │   └── descriptions/
    │       ├── MessageDescription.ts
    │       ├── InstanceDescription.ts
    │       ├── CampaignDescription.ts
    │       ├── VcashDescription.ts
    │       └── EmailDescription.ts
    └── Whats360Trigger/
        ├── Whats360Trigger.node.json
        └── Whats360Trigger.node.ts

فصل أوصاف الحقول والعمليات عن الملف الرئيسي للعقدة يجعل إضافة Resource جديد أكثر سهولة، كما يسمح بتعديل واجهة المستخدم دون تحويل ملف التنفيذ الرئيسي إلى ملف ضخم يصعب صيانته.

عقدة Whats360 Trigger واستقبال الأحداث

إلى جانب Node التنفيذ، تحتوي الحزمة على Trigger مخصص لاستقبال Webhooks من Whats360.

يمكن استخدام هذه العقدة كنقطة دخول إلى Workflow عند وصول رسالة جديدة أو حدوث حدث آخر تدعمه المنصة.

export class Whats360Trigger implements INodeType {
	description: INodeTypeDescription = {
		displayName: 'Whats360 Trigger',
		name: 'whats360Trigger',
		icon: 'file:whats360.svg',
		group: ['trigger'],
		version: 1,
		description:
			'Receives real-time incoming messages, status updates, and events from Whats360',
		defaults: {
			name: 'Whats360 Trigger',
		},
		inputs: [],
		outputs: ['main'],
		webhooks: [
			{
				name: 'default',
				httpMethod: 'POST',
				responseMode: 'onReceived',
				path: 'webhook',
			},
		],
	};
}

ويتم توحيد البيانات القادمة من Webhook إلى بنية موحدة يمكن لباقي العقد في n8n التعامل معها بسهولة.

const normalized = {
	sender_phone: bodyData.phone || bodyData.from || '',
	sender_name: bodyData.sender_name || bodyData.name || '',
	message:
		bodyData.message ||
		bodyData.msg ||
		bodyData.body ||
		'',
	message_id:
		bodyData.message_id ||
		bodyData.id ||
		'',
	chat_jid:
		bodyData.chat_jid ||
		'',
	instance_id:
		bodyData.instance_id ||
		'',
	timestamp:
		bodyData.timestamp ||
		Date.now(),
	media_url:
		bodyData.media_url ||
		null,
	raw: bodyData,
};

وجود الحقل raw مهم أيضًا لأنه يحتفظ بالبيانات الأصلية القادمة من Webhook، بينما توفر الحقول الموحدة طبقة أبسط للاستخدام في العقد التالية.

حماية Webhook باستخدام Secret Header

يمكن للعقدة كذلك التحقق من Secret Header عند تفعيله، بحيث لا يتم قبول الطلبات التي لا تحتوي على القيمة الصحيحة.

if (secretHeader) {
	const incomingSecret =
		req.headers['x-hook-secret'] ||
		req.headers['x-secret-key'];

	if (incomingSecret !== secretHeader) {
		return {
			webhookResponse: {
				status: 'error',
				message:
					'Unauthorized: Invalid Secret Header',
			},
		};
	}
}

هذه الطبقة تضيف تحققًا بسيطًا ومباشرًا قبل تمرير بيانات الحدث إلى Workflow.

ما الذي يجب تأجيله إلى إصدارات لاحقة؟

من المهم ألا تتم إضافة عمليات غير مؤكدة في API إلى الإصدار الأول للحزمة. لذلك توجد مجموعة من الوظائف التي يمكن وضعها ضمن Roadmap إلى أن تتوفر Endpoints رسمية وواضحة لها.

الميزة	الحالة	سبب التأجيل
إدارة جهات الاتصال	Pending	تحتاج إلى Endpoint رسمي
تصدير سجل المحادثات	Pending	تحتاج إلى API معتمد
Interactive Buttons & Lists	Pending	تحتاج إلى Endpoint رسمي

هذا الفصل بين العمليات المؤكدة والعمليات المقترحة يحافظ على استقرار الإصدار الأول ويمنع بناء Features تعتمد على API غير متاح أو غير موثق.

مسارات عمل جاهزة يمكن بناؤها فوق العقدة

وكيل دعم فني عبر WhatsApp

يمكن إنشاء Workflow يستقبل الرسالة الواردة من Whats360 Trigger، ثم يرسل النص إلى AI Agent، وبعد توليد الإجابة يمررها إلى Whats360 Node لإرسال الرد إلى العميل.

[Whats360 Trigger]
       ↓
[AI Agent / LangChain Node]
       ↓
[AI Generated Response]
       ↓
[Whats360 - Send Text]
       ↓
[Customer]

وبذلك يمكن فصل طبقة الذكاء الاصطناعي عن طبقة الاتصال، بحيث يصبح Whats360 مسؤولًا عن قناة WhatsApp، بينما يدير n8n منطق الوكيل والأدوات والتكاملات.

تأكيد الطلبات في المتجر

يمكن تشغيل Workflow عند إنشاء الطلب، ثم استخراج رقم العميل وإنشاء ملخص الطلب، وبعدها إرسال رسالة تلقائية عبر WhatsApp.

[WooCommerce Trigger]
       ↓
[Code / Set]
       ↓
[Format Order Summary]
       ↓
[Whats360 - Send Text]

إشعار فريق المبيعات بوصول Lead جديد

يمكن كذلك استقبال Lead جديد، ثم التواصل معه مباشرة عبر WhatsApp وإرسال تنبيه إلى مندوب المبيعات عبر SMS.

[Facebook Lead Ads Trigger]
       ↓
[Whats360 - WhatsApp Message]
       ↓
[VCash - SMS Alert]
       ↓
[Sales Team]

متطلبات نشر n8n-nodes-whats360

بعد الانتهاء من تطوير العقدة واختبار العمليات الأساسية، تأتي مرحلة تجهيز الحزمة للنشر بحيث يمكن تثبيتها داخل بيئات n8n المختلفة.

بناء الحزمة

يبدأ تجهيز المشروع بتثبيت الاعتمادات ثم تشغيل عملية البناء:

npm install
npm run build

يؤدي أمر البناء إلى ترجمة ملفات TypeScript وإنشاء الملفات المطلوبة داخل مجلد dist وفق إعدادات المشروع.

اختبار العقدة محليًا

قبل النشر العام، يمكن اختبار الحزمة داخل بيئة n8n محلية باستخدام الربط المحلي:

npm link /path/to/n8n-nodes-whats360

وهذه المرحلة مهمة لاختبار واجهة العقدة، الـ Credentials، القوائم الديناميكية، تنفيذ الطلبات، معالجة الأخطاء، والـ Webhook Trigger قبل إتاحة الحزمة للمستخدمين.

نشر الحزمة على npm

بعد التأكد من نجاح البناء والاختبارات، يمكن تسجيل الدخول إلى npm ثم نشر الحزمة:

npm login
npm publish --access public

بعد نشر الحزمة باسم n8n-nodes-whats360 تصبح جاهزة للتثبيت في بيئات n8n التي تسمح باستخدام Community Nodes.

تثبيت العقدة داخل n8n

بعد نشر الحزمة يمكن تثبيتها من إعدادات Community Nodes داخل n8n، باستخدام اسم الحزمة:

n8n-nodes-whats360

وبمجرد تثبيتها وظهورها داخل محرر Workflow، يستطيع المستخدم إنشاء Credential خاص بـ Whats360 ثم البدء في استخدام الموارد والعمليات التي توفرها العقدة.

استراتيجية إطلاق n8n-nodes-whats360

نجاح الـ Community Node لا يعتمد على الكود وحده. فبعد توفير التكامل، يجب بناء منظومة تجعل المطور أو صاحب المشروع قادرًا على فهم قيمة التكامل وتطبيقه بسرعة.

الوصول إلى مجتمع n8n

الهدف الأساسي هو تقديم الحزمة باعتبارها تكاملًا عمليًا يربط WhatsApp وSMS والبريد الإلكتروني والحملات مع بيئة الأتمتة.

وجود العقدة داخل منظومة Community Nodes يتيح للمستخدم الوصول إلى التكامل من داخل بيئة n8n بدل البحث عن طريقة اتصال API يدويًا.

مكتبة Workflows جاهزة

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

يمكن أن تتضمن المكتبة سيناريوهات مثل تأكيد الطلبات، إشعارات الدفع، الردود الآلية، متابعة العملاء المحتملين، خدمة العملاء، وربط المتاجر الإلكترونية مع WhatsApp.

القيمة هنا ليست في العقدة وحدها، وإنما في تحويلها إلى مكونات جاهزة لحالات استخدام حقيقية.

محتوى تعليمي قصير

يمكن تقديم شروحات عملية توضح كيفية بناء التكامل في دقائق، مثل إنشاء Credential، اختيار الجهاز، إرسال رسالة، استقبال Webhook، ثم ربط الرسالة مع AI Agent.

هذا النوع من المحتوى يساعد المطور على الانتقال من فكرة التكامل إلى Workflow يعمل فعليًا بأقل عدد ممكن من الخطوات.

خريطة تطوير الإصدارات القادمة

الإصدار الأول يضع الأساس للتكامل، بينما يمكن استخدام الإصدارات اللاحقة لتوسيع إمكانيات العقدة وفق الـ Endpoints التي يتم اعتمادها رسميًا في API.

الإصدار الأول

يدعم الإصدار الحالي العمليات الأساسية الخاصة برسائل WhatsApp النصية والوسائط، وإدارة Instances، والحملات، وVCash، والبريد الإلكتروني، بالإضافة إلى Webhook Trigger.

الإصدار التالي

يمكن توسيع العقدة لإضافة الرسائل التفاعلية مثل Buttons وLists بمجرد توفير واعتماد الـ Endpoints الرسمية الخاصة بهذه الوظائف.

التكامل المتقدم

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

ملاحظات مهمة قبل اعتماد الكود للإنتاج

رغم أن الهيكل البرمجي يوضح بصورة عملية كيفية بناء العقدة، فإن اعتمادها كحزمة Production يتطلب اختبار كل Endpoint فعليًا مع الاستجابات الحقيقية للـ API، خصوصًا العمليات التي تعتمد على شكل Payload محدد أو أكواد أخطاء خاصة.

كما يجب التأكد من تطابق أسماء الحقول في الـ API مع الحقول المستخدمة داخل العقدة، واختبار حالات النجاح والفشل، والـ Credentials، والـ Webhook Security، والتعامل مع أكثر من Item داخل Workflow.

ومن المهم أيضًا عدم إضافة أي عملية جديدة إلى العقدة لمجرد توقع وجود Endpoint لها. العمليات غير المؤكدة يجب أن تظل خارج الكود إلى أن تتوفر لها واجهة API رسمية يمكن اختبارها وتوثيقها.

التعامل مع أرقام WhatsApp

توحيد الرقم قبل الإرسال من أهم الوظائف التي تقلل الأخطاء في Workflow. فبدل مطالبة المستخدم بإدخال JID يدويًا، تقوم الدالة formatToJid بمعالجة الرقم وإضافة النطاق المناسب.

formatToJid('+201234567890')
formatToJid('201234567890')
formatToJid('00201234567890')

والنتيجة تكون بصيغة:

201234567890@s.whatsapp.net

أما إذا تم تمرير JID موجود بالفعل، مثل 201234567890@s.whatsapp.net أو JID لمجموعة WhatsApp، فلا تتم إعادة تنسيقه.

معالجة أخطاء API

من العناصر المهمة في تجربة المطور ألا تكتفي العقدة بعرض رقم HTTP Error، بل تقدم تفسيرًا يساعده على معرفة الخطوة التالية.

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

وبالمثل، يتم التعامل مع أخطاء المصادقة 401 وأخطاء عدم العثور على Instance أو Device عند ظهور 404، وكذلك حدود الحساب عند ظهور 403.

أسئلة شائعة حول n8n وWhats360

ما وظيفة n8n-nodes-whats360؟

هي Community Node مصممة لربط Whats360 مع n8n، بحيث يمكن تنفيذ عمليات WhatsApp والحملات وSMS وUSSD والبريد الإلكتروني من داخل Workflows بدل الاعتماد على HTTP Requests مكتوبة يدويًا لكل عملية.

هل يمكن استخدام Whats360 مع AI Agents داخل n8n؟

نعم، التصميم المقترح يستهدف هذا الاستخدام تحديدًا، بحيث يمكن استقبال رسالة عبر Whats360 Trigger، تمريرها إلى AI Agent أو LangChain، ثم استخدام Whats360 Node لإرسال الرد الناتج إلى العميل.

هل يحتاج المستخدم إلى كتابة JID يدويًا؟

لا. وظيفة formatToJid مصممة لتحويل صيغ أرقام الهاتف المختلفة إلى JID مناسب عند الحاجة.

هل يمكن اختيار Instance من قائمة؟

نعم. تعتمد العقدة على loadOptionsMethod لجلب Instances من API وعرضها في قائمة ديناميكية داخل واجهة n8n.

هل تدعم العقدة الحملات التسويقية؟

نعم، وفق العمليات المحددة في المخطط، تشمل إدارة الحملات إنشاء الحملة، إضافة المستلمين، التشغيل، الإيقاف المؤقت، الاستئناف، الإيقاف، عرض الحالة، والحذف.

هل يمكن استخدام VCash داخل نفس Workflow؟

نعم. التصميم يتضمن عمليات إرسال SMS وتنفيذ USSD والحصول على الرصيد والمعاملات وإدارة أجهزة VCash، مما يسمح بدمج أكثر من قناة اتصال داخل Workflow واحد.

هل يمكن ربط WooCommerce أو Shopify مع Whats360؟

نعم، الفكرة الأساسية هي استقبال حدث الطلب من منصة التجارة الإلكترونية، تجهيز البيانات داخل n8n، ثم تمرير رقم العميل وملخص الطلب إلى Whats360 لإرسال إشعار WhatsApp تلقائي.

هل يمكن استقبال الرسائل الواردة من Whats360 داخل n8n؟

نعم، من خلال Whats360 Trigger الذي يستقبل Webhook ويقوم بتوحيد أهم بيانات الحدث، مثل رقم المرسل، الاسم، الرسالة، Message ID، Instance ID، الوقت، ورابط الوسائط إن وجد.

هل يمكن حماية Webhook؟

يتضمن التصميم خيارًا اختياريًا لـ Secret Header، بحيث يمكن مقارنة قيمة X-Hook-Secret أو X-Secret-Key بالقيمة المحددة في إعدادات العقدة.

هل كل العمليات المقترحة مؤكدة في API؟

لا. العمليات الخاصة بإدارة جهات الاتصال وتصدير سجل المحادثات والرسائل التفاعلية تم تصنيفها كعمليات تحتاج إلى تأكيد Endpoint رسمي قبل إضافتها إلى الكود.

الخلاصة

تطوير n8n-nodes-whats360 يحول التكامل بين WhatsApp وبيئة n8n من مجموعة طلبات API منفصلة إلى تجربة أتمتة متكاملة يمكن استخدامها من قبل المطورين وأصحاب الشركات ومطوري AI Agents.

القيمة الأساسية في التصميم ليست فقط في إرسال رسالة WhatsApp، وإنما في بناء طبقة تكامل تسمح بإدارة الرسائل والأجهزة والحملات وSMS وUSSD والبريد الإلكتروني وWebhooks من داخل Workflow واحد.

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

أما التطوير المستقبلي فيمكن أن يركز على الرسائل التفاعلية، ومزامنة جهات الاتصال، وسجل المحادثات، والتكاملات الأوسع مع أنظمة CRM، بشرط اعتماد الـ Endpoints الرسمية الخاصة بهذه الوظائف.

مقالات ذات صلة

• أتمتة WhatsApp باستخدام n8n
• ربط WhatsApp مع AI Agents
• ربط WhatsApp مع WooCommerce
• أتمتة API باستخدام n8n