ربط WhatsApp بـ Bitrix24 CRM على رقم Coexistence

كيف يتحدث n8n مع Bitrix24؟

عبر webhook وارد، وهو في Bitrix24 ليس مستقبِلًا بل بيانات اعتماد. تنشئه في موارد المطورين في Bitrix24، وتحدد النطاقات المسموح له باستخدامها، فتحصل على عنوان URL يحوي عنوان البوابة ومعرّف المستخدم الذي أنشأه ورمزًا سريًا. إضافة اسم دالة إلى هذا العنوان تستدعي واجهة برمجة التطبيقات (API) الخاصة بـ REST بصفة ذلك المستخدم وبصلاحياته.

لذلك تكون كل خطوة Bitrix24 في n8n عقدة HTTP Request ترسل إلى ذلك العنوان مع دالة مثل crm.lead.add.json. لا توجد دورة OAuth لإكمالها ولا تطبيق لنشره. امنح webhook نطاق CRM وحده، وأنشئه من مستخدم تشمل صلاحياته العملاء المحتملين وجهات الاتصال التي يجب أن يراها سير العمل، لأن Bitrix24 يتحقق من الوصول بصفة هذا المستخدم.

ما دوال Bitrix24 التي يستدعيها سير العمل؟

ثلاث، بالترتيب، بعد أن تستقبل عقدة Webhook في n8n الرسالة من Meta.

تعيد crm.duplicate.findbycomm مع النوع PHONE ورقم المرسل معرّفات أي عملاء محتملين وجهات اتصال وشركات تحمل هذا الرقم. وهذا هو البحث الصحيح لأنه يفحص الثلاثة دفعة واحدة، ومصمم للمطابقة على وسائل الاتصال لا على حقل نصي.

وحين لا تعيد شيئًا، تنشئ crm.lead.add عميلًا محتملًا عنوانه اسم ملف WhatsApp الشخصي، ويوضع الرقم في حقل الهاتف. ثم تكتب crm.timeline.comment.add نص الرسالة تعليقًا على الكيان، وتأخذ ENTITY_TYPE وENTITY_ID وCOMMENT. يظهر التعليق في السجل الزمني للكيان بجانب المكالمات والبريد الإلكتروني، حيث ينظر مندوب المبيعات أصلًا.

POST https://yourcompany.bitrix24.com/rest/1/<secret>/crm.duplicate.findbycomm.json
{ "type": "PHONE", "values": ["14155550188"] }

POST .../crm.lead.add.json
{ "fields": { "TITLE": "WhatsApp: Maria", "PHONE": [{ "VALUE": "14155550188", "VALUE_TYPE": "MOBILE" }] } }

POST .../crm.timeline.comment.add.json
{ "fields": { "ENTITY_TYPE": "lead", "ENTITY_ID": 4211, "COMMENT": "do you have anything friday?" } }

كيف يؤثر حد المعدل في سير العمل؟

يقيس Bitrix24 استدعاءات REST بنظام الدلو المتسرب. كل طلب يزيد عدادًا، ويتناقص العداد بمعدل ثابت كل ثانية، وحين يتجاوز عتبة معينة يتلقى الطلب التالي الحالة 503 مع QUERY_LIMIT_EXCEEDED. في خطط Enterprise يتناقص العداد بمقدار 5 في الثانية مع عتبة 250، وفي كل الخطط الأخرى بمقدار 2 مع عتبة 50.

تكلف كل رسالة واردة استدعاءين أو ثلاثة، فلا يقترب منها التدفق البطيء المستمر. أما الدفعة المفاجئة فتقترب: 50 عميلًا يردون على القالب نفسه خلال دقيقة تعني حتى 150 استدعاء. اضبط عقد HTTP Request على إعادة المحاولة عند الفشل بعد انتظار قصير، وشغّل تنفيذات سير العمل واحدًا تلو الآخر، ليتسرب الضغط تدريجيًا إلى Bitrix24 بدل أن يرتد عنه.

هل تصل الردود المكتوبة على الهاتف إلى Bitrix24؟

يمكن ذلك. على رقم Coexistence يواصل تطبيق WhatsApp Business العمل، وحين يرد أحد منه ترسل Meta صدى للرسالة الصادرة إلى وجهة webhook نفسها، ضمن الحقل smb_message_echoes.

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

أما الردود التي يرسلها سير العمل نفسه عبر Cloud API فهي بين يديه أصلًا لحظة خروجها، فسجّلها في تلك اللحظة بدل انتظار webhook يرجع بها.

الأخطاء الشائعة

• لصق عنوان URL الخاص بالـ webhook الوارد في شيفرة جانب العميل أو في مستند مشترك. فالرمز السري فيه يمنح كل نطاق مُنح له.
• إنشاء webhook من مستخدم لا يرى كل العملاء المحتملين. عندها تفوت عمليات البحث بعض السجلات، فينشئ سير العمل نسخًا مكررة.
• إرسال دفعة استدعاءات دون إعادة محاولة. يرد Bitrix24 بـ 503 QUERY_LIMIT_EXCEEDED، ولا تصل تلك الرسائل إلى السجل الزمني أبدًا.

الأسئلة الشائعة

تابع القراءة