חיבור WhatsApp ל-Bitrix24 CRM במספר Coexistence

איך n8n מדבר עם Bitrix24?

דרך וובהוק נכנס, שב-Bitrix24 הוא לא מקבל נתונים אלא פרטי גישה. יוצרים אותו במשאבי המפתחים של Bitrix24, בוחרים את ההרשאות (scopes) שמותר לו להשתמש בהן, ומקבלים כתובת URL שמכילה את כתובת הפורטל, את המזהה של המשתמש שיצר אותו וקוד סודי. הוספת שם של שיטה לכתובת הזו מפעילה את ה-REST API בשם אותו משתמש, עם ההרשאות שלו.

לכן ב-n8n כל שלב מול Bitrix24 הוא צומת HTTP Request ששולח בקשת POST לכתובת הזו, בתוספת שיטה כמו crm.lead.add.json. אין תהליך OAuth להשלים ואין אפליקציה לפרסם. מעניקים לוובהוק הרשאת 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.

כל הודעה נכנסת עולה שתיים או שלוש קריאות, ולכן זרם יציב לא מתקרב למגבלה. פרץ כן מגיע אליה: חמישים לקוחות שעונים לאותה תבנית בתוך דקה הם עד 150 קריאות. מגדירים בצמתי HTTP Request ניסיון חוזר בכישלון עם המתנה קצרה, ומריצים את ההרצות של התהליך אחת בכל פעם, כך שהפרץ נספג ב-Bitrix24 ולא נדחה ממנה.

האם תשובות שנכתבות בטלפון מגיעות ל-Bitrix24?

הן יכולות. במספר Coexistence אפליקציית WhatsApp Business ממשיכה לעבוד, וכשמישהו עונה ממנה, Meta שולחת הד של ההודעה היוצאת לאותו יעד של הוובהוק, בשדה smb_message_echoes.

ענף שני בתהליך מטפל בהדים האלה כמו בהודעות נכנסות, כשההערה מסומנת כיוצאת. כך הרשומה מציגה את השיחה המלאה, עם דברי הלקוח ותשובות העסק לפי הסדר.

תשובות שהתהליך שולח בעצמו דרך ה-Cloud API כבר נמצאות בידי התהליך ברגע שהן יוצאות, ולכן רושמים אותן באותו רגע ולא מחכים לוובהוק שיחזור.

טעויות נפוצות

• הדבקת כתובת ה-URL של הוובהוק הנכנס בקוד צד לקוח או במסמך משותף. הקוד הסודי שבה נותן את כל ההרשאות שהוענקו לוובהוק.
• יצירת הוובהוק ממשתמש שאינו רואה את כל הלידים. החיפושים מפספסים רשומות והתהליך יוצר כפילויות.
• שליחת פרץ קריאות בלי ניסיונות חוזרים. Bitrix24 עונה 503 QUERY_LIMIT_EXCEEDED, וההודעות האלה לא מגיעות לציר הזמן.

שאלות נפוצות

המשיכו לקרוא