וואטסאפ ביזנס API (WhatsApp Business API): חיבור, עלויות ומגבלות

WhatsApp Business API, או בעברית וואטסאפ ביזנס API, הוא הממשק של Meta לשליחה וקבלה של הודעות וואטסאפ מתוך מערכת עסקית, ובשנת 2026 המשמעות היא Cloud API בלבד - שירות שמתארח אצל Meta ונקרא דרך Graph API. גרסת ה-On-Premises הפסיקה למסור הודעות ב-23 באוקטובר 2025. חיבור מספר דורש חמש קריאות בסדר קבוע, ותקלה בהודעות נכנסות היא כמעט תמיד שלב שדילגו עליו.

מה זה WhatsApp Business API היום?

WhatsApp Business API (שנכתב בחיפוש גם ווטסאפ API) הוא הדרך לשלוח ולקבל הודעות מתוך תוכנה משלכם - CRM, ERP, מערכת זימון תורים - ולא מאפליקציית WhatsApp Business בטלפון. מאז שגרסת ה-On-Premises הושבתה, קיימת רק גרסה אחת והיא Cloud API. לפי לוח הזמנים ש-Meta פרסמה:

• מ-1 ביולי 2024 אפשר לרשום מספר עסקי רק ל-Cloud API. ניסיון לרשום מספר ל-On-Premises מחזיר קוד שגיאה 1005.
• ב-23 באוקטובר 2025 פגה גרסת ה-On-Premises האחרונה, v2.63, והודעות אל מספרים שעדיין רשומים בה או מהם לא נמסרות.
• תיק עסקי חדש (business portfolio, מה שנקרא בעבר Business Manager) מוגבל בהתחלה לשני מספרים עסקיים רשומים.

מדריך שעדיין מציע לבחור בין Cloud ל-On-Premises פשוט לא מעודכן. אם השאלה היא בכלל אם אתם צריכים API או שהאפליקציה מספיקה, ראו אפליקציית WhatsApp Business מול ה-API.

כמה עולה וואטסאפ ביזנס API, ומה משתנה ב-1 באוקטובר 2026?

מאז 1 ביולי 2025 Meta גובה לפי הודעת תבנית שנמסרה, והתעריף נקבע לפי הקטגוריה של התבנית (marketing, utility או authentication) ולפי קידומת המדינה של הנמען. לישראל (972) יש שורה משלה בטבלת התעריפים. עד 30 בספטמבר 2026 תשובות חופשיות בתוך חלון השירות לא עלו כלום. לפי עמוד התמחור של Meta, נכון לספטמבר 2026, זה המצב לפני השינוי ואחריו:

המכסה החינמית של 1,000 הודעות service היא לכל מספר עסקי, מתאפסת כל חודש ולא עוברת לחודש הבא, והודעות לקבוצות נספרות ממנה לפי כל נמען שקיבל. לתעריפים העדכניים לישראל ולחישוב עלות לדוגמה, ראו תמחור WhatsApp Business API.

חלון השירות וקטגוריות התבניות

חלון השירות (customer service window) הוא טיימר של 24 שעות שמתחיל כשמשתמש כותב למספר העסקי או מתקשר אליו, ומתאפס בכל הודעה או שיחה נוספת ממנו. כל עוד החלון פתוח אפשר לשלוח כל סוג הודעה. אחרי שהוא נסגר אפשר לשלוח רק תבנית מאושרת, והודעה חופשית תיכשל בקוד 131047. שלוש הקטגוריות:

• Marketing - מודעות, מבצעים, החזרת לקוחות. הקטגוריה הגמישה ביותר.
• Utility - חייבת להיות לא שיווקית, וגם ספציפית למשתמש (הזמנה, חשבון, עסקה) או חיונית לו.
• Authentication - הקטגוריה היחידה שמותר לשלוח בה קוד חד-פעמי לאימות זהות.

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

לכמה אנשים מספר חדש יכול לשלוח ביום?

תיק עסקי חדש יכול למסור הודעות ל-250 משתמשי WhatsApp ייחודיים ב-24 שעות נעות, והספירה היא רק של הודעות מחוץ לחלון השירות. המגבלה נקבעת ברמת התיק העסקי ומשותפת לכל המספרים שבו, כך שמספר אחד יכול לנצל את כולה. תשובות למי שכתב אליכם לא נספרות.

• 2,000 - דורש אחד משלושה מסלולים: אימות העסק, אימות דרך השותף שדרכו נרשמתם, או מסירה של 2,000 הודעות לנמענים ייחודיים מחוץ לחלון השירות תוך 30 יום בתבניות עם דירוג איכות גבוה.
• 10,000, 100,000 ובלי הגבלה - עלייה אוטומטית, דרגה אחת בכל פעם ובתוך 6 שעות, כשאיכות ההודעות גבוהה והשתמשתם לפחות בחצי מהמגבלה הנוכחית ב-7 הימים האחרונים.

כדי לקרוא את המגבלה ב-API מבקשים את השדה whatsapp_business_manager_messaging_limit על המספר. השדה הישן messaging_limit_tier הוצא משימוש, וקוד שעדיין קורא אותו צריך עדכון. את אימות העסק כדאי לפתוח במקביל לפיתוח, לא ביום העלייה לאוויר.

חיבור מספר ל-Cloud API: סדר הפעולות

הסדר חשוב כי שני שלבים נכשלים בלי שגיאה. לפני שמתחילים צריך תיק עסקי, אפליקציית Meta עם מוצר WhatsApp (app_id ו-app_secret), חשבון WABA עם waba_id, מספר עם phone_number_id, טוקן של System User עם ההרשאה whatsapp_business_messaging, ונקודת קצה ציבורית ב-HTTPS שכבר פרוסה. טוקן זמני מ-Graph API Explorer ייפול בהמשך עם קוד 190, שמשמעותו טוקן שפג תוקפו.

1. מזהה המספר. GET /{waba_id}/phone_numbers. מזהה המספר הוא לא מספר הטלפון, וכמעט כל קריאה אחרת משתמשת בו.
2. webhook ברמת האפליקציה. POST /{app_id}/subscriptions עם object=whatsapp_business_account, callback_url, verify_token, fields, ו-App Access Token בצורה APP_ID|APP_SECRET - לא טוקן ההודעות. Meta שולחת את בקשת האימות מסוג GET ל-callback_url בתוך הקריאה הזו, ולכן השרת חייב כבר להחזיר 200 עם ערך hub.challenge.
3. חיבור ה-WABA לאפליקציה. POST /{waba_id}/subscribed_apps. זו קריאה נפרדת שלא קורית אוטומטית. בלעדיה שליחה יוצאת עובדת ואף הודעה נכנסת לא מגיעה. בודקים עם GET על אותה כתובת.
4. רישום המספר. POST /{phone_number_id}/register עם messaging_product: "whatsapp" ו-pin בן 6 ספרות. אם אימות דו-שלבי כבר פעיל, ה-PIN חייב להיות הקוד הקיים. אם לא, הערך ששולחים הופך ל-PIN החדש. מותרות 10 בקשות למספר ב-72 שעות נעות, והבקשה ה-11 מחזירה 133016 וחוסמת רישום ל-72 שעות. מספר לא רשום נכשל בכל שליחה עם 133010 או 131045.
5. בדיקת תקינות. GET /{phone_number_id}?fields=health_status. השדה can_send_message מחזיר AVAILABLE, LIMITED או BLOCKED, בסיכום של כל הרכיבים שמעורבים בשליחה: האפליקציה, התיק העסקי, ה-WABA, המספר והתבנית. במצב BLOCKED מצורף errors עם הסיבה.

ב-fields כדאי להירשם לפחות ל-messages, ל-message_template_status_update, ל-message_template_quality_update, ל-template_category_update ול-user_id_update. הפירוש של כל קוד שגיאה נמצא במדריך קודי השגיאה של WhatsApp Cloud API, והבנייה של בוט מעל החיבור הזה באיך בונים בוט וואטסאפ.

טיפול ב-webhook הנכנס

נקודת הקצה של ה-webhook מקבלת שני סוגי בקשות, ולכל אחד כלל משלו:

• GET לאימות. משווים את hub.verify_token למחרוזת השמורה אצלכם. אם יש התאמה מחזירים 200 עם ערך hub.challenge, ואם לא - קוד 400 ומעלה.
• POST לאירועים. הכותרת X-Hub-Signature-256 מכילה sha256= ואחריו HMAC-SHA256 של גוף הבקשה, עם ה-app secret כמפתח. מחשבים אותו על הבייטים הגולמיים: JSON שפורסר ונכתב מחדש משנה סדר מפתחות ורווחים, והחתימה לא תתאים. מאחורי proxy, נתיב ה-webhook צריך להיות ממופה לפני ה-body parser.
• מחזירים 200 מהר. על כל תשובה שאינה 200, Meta שולחת שוב בתדירות יורדת במשך עד 7 ימים, והשליחה החוזרת מגיעה לכל אפליקציה שרשומה ל-WABA. לכן כפילויות הן מצב רגיל, ויש לסנן אותן לפי מזהה ההודעה.
• גודל. payload של webhook יכול להגיע עד 3 MB.

למה webhook מגיע בלי מספר הטלפון של הלקוח?

מאז תחילת אפריל 2026 כל webhook של הודעות נושא מזהה משתמש ברמת העסק (business-scoped user ID, או BSUID) בשדה user_id, ומשתמש שאימץ שם משתמש ב-WhatsApp יכול להגיע בלי מספר טלפון בכלל. לפי התיעוד של Meta, המספר נכלל רק אם שלחתם הודעה למספר הזה או התקשרתם אליו ב-30 הימים האחרונים, אם הוא כתב אליכם או התקשר ב-30 הימים האחרונים, או אם הוא נמצא בספר אנשי הקשר (contact book) שלכם. תנאי 30 הימים נבדק בנפרד לכל מספר עסקי.

• מבנה ה-BSUID: קוד מדינה בן שתי אותיות, נקודה, ועד 128 תווים אלפאנומריים, למשל US.13491208655302741918. הוא ייחודי לצמד של תיק עסקי ומשתמש.
• ה-BSUID נוצר מחדש כשהמשתמש מחליף מספר טלפון, ואירוע user_id_update מודיע על כך.
• לשליחה ל-BSUID ממלאים recipient ומשמיטים את to. זה עובד לכל סוג הודעה חוץ מתבניות authentication מסוג one-tap, zero-tap ו-copy code.
• אינטגרציה שמזהה לקוח רק לפי wa_id תפיל הודעות כאלה בלי שום התראה. צריך לשמור את שני המזהים ולחפש לפי שניהם.

לכמה עולה לבנות ולתחזק מערכת כזו, ראו כמה עולה צ'אטבוט.

מקורות

• Meta - Pricing on the WhatsApp Business Platform
• Meta - Messaging Limits
• Meta - Business-scoped user IDs