סטטוס מסירה בוואטסאפ: המדריך הטכני ל-Meta Cloud API

סטטוס מסירה בוואטסאפ הוא חיווי אירוע אסינכרוני הנשלח דרך Webhook משרתי Meta למערכת שלכם, ומציין את השלב המדויק שבו נמצאת ההודעה: נשלחה (sent), נמסרה למכשיר היעד (delivered), נקראה (read), או נכשלה (failed). ניטור רציף ושיטתי של סטטוסים אלו מאפשר לחנויות איקומרס לזהות חסימות, שגיאות מסירה ומספרים שגויים בזמן אמת, ולתקן תקלות תשתיתיות לפני שהן פוגעות בחוויית הלקוח או בהכנסות העסק. במדריך זה נפרק את ארכיטקטורת הסטטוסים של WhatsApp Cloud API, נבחן את מבנה המידע הנכנס ונלמד כיצד לטפל בכשלים בצורה אוטומטית.

ארבעת שלבי מחזור החיים של הודעה ב-WhatsApp Cloud API

כל הודעה יוצאת שנשלחת דרך ה-API עוברת מסלול קבוע משרת השולח ועד למכשיר הקצה. לאחר שליחת בקשת HTTP מסוג POST לנקודת הקצה של ההודעות, השרת מקבל תגובה מיידית המאשרת את קבלת הבקשה וכוללת מזהה הודעה ייחודי (wamid). מרגע זה ואילך, עדכוני המצב מתקבלים אך ורק באמצעות התראות Webhook אסינכרוניות.

התרשים הבא מפרט את ארבעת הסטטוסים, המשמעות התשתיתית שלהם והפעולה הנדרשת במערכת הניהול שלכם:

סטטוס API	משמעות טכנית	חיווי גרפי בצ'אט	משמעות עסקית ופעולה נדרשת
sent	ההודעה נקלטה ועובדה בשרתי Meta	וי אפור בודד	הבקשה תקינה ותור ההפצה פועל. אין צורך בפעולה.
delivered	ההודעה הגיעה בהצלחה למכשיר הנמען	שני וי אפורים	המכשיר מחובר לרשת. ההודעה ממתינה לפתיחה.
read	הנמען פתח את שיחת הוואטסאפ	שני וי כחולים	חשיפה מלאה להודעה. ניתן לתזמן מעקב נוסף.
failed	ההודעה לא נמסרה, מצורף קוד שגיאה	סימן קריאה אדום	כשל במסירה. יש לנתח את קוד השגיאה ולהפעיל גיבוי.

הבנת ההבדל בין sent ל-delivered היא קריטית: sent מעיד רק על כך ש-Meta קיבלה את ההודעה. אם מכשיר הנמען כבוי, מנותק מחיבור אינטרנט או שחשבונו הושעה, ההודעה תישאר במצב sent עד 30 יום לפני שתפוג.

קריאת נתוני Webhook וזיהוי סטטוס מסירה בזמן אמת

כאשר חל שינוי במצב ההודעה, שרתי Meta שולחים בקשת POST לכתובת ה-Webhook שהגדרתם. מבנה המידע (Payload) מכיל שדות ספציפיים שמאפשרים לשייך את העדכון להודעה וללקוח המתאים. מידע מלא על מבנה האובייקטים מתועד במסמכי Meta Webhooks Components.

{
  "object": "whatsapp_business_account",
  "entry": [{
    "id": "WHATSAPP_BUSINESS_ACCOUNT_ID",
    "changes": [{
      "value": {
        "messaging_product": "whatsapp",
        "metadata": {
          "display_phone_number": "972500000000",
          "phone_number_id": "PHONE_NUMBER_ID"
        },
        "statuses": [{
          "id": "wamid.HBgLMTY1...",
          "status": "delivered",
          "timestamp": "1711200000",
          "recipient_id": "972520000000",
          "conversation": {
            "id": "CONVERSATION_ID",
            "origin": {
              "type": "utility"
            }
          },
          "pricing": {
            "billable": true,
            "pricing_model": "CBP",
            "category": "utility"
          }
        }]
      },
      "field": "messages"
    }]
  }]
}

בבניית מערכת קליטה יש לשים לב לשלושה היבטים מרכזיים:

1. סדר הגעת האירועים אינו מובטח: עקב ניתוב ברשתות מבוזרות, ייתכן שאירוע read יגיע לשרת שלכם שבריר שנייה לפני אירוע delivered. המערכת חייבת להיות מתוכננת כך שסטטוס מתקדם לא יידרס על ידי סטטוס קודם שמגיע באיחור.
2. הגדרות פרטיות של הנמען: אם הנמען ביטל את הצגת "אישורי קריאה" (Read Receipts) בהגדרות הוואטסאפ שלו, שרתי Meta לעולם לא ישלחו עבורו אירוע read. במצב זה, הסטטוס האחרון שתקבלו יהיה delivered גם אם הלקוח הגיב להודעה בפועל.
3. חיוב לפי שיחה: ה-Webhook של הסטטוס כולל את אובייקט ה-pricing. אירוע ה-sent הראשון בחלון 24 שעות מגדיר את קטגוריית השיחה (Utility, Marketing או Service) ומתחיל את חלון החיוב מול Meta.

ניתוח שגיאות כאשר סטטוס מסירה בוואטסאפ הופך ל-failed

הסטטוס החשוב ביותר לניטור בחנויות מסחר מקוון הוא failed. כאשר הודעה אינה נמסרת, Meta מחזירה מערך errors בתוך אובייקט הסטטוס. המערך כולל קוד שגיאה מספרי, כותרת, ולעיתים פרטי שגיאה מורחבים. תיעוד מלא של כלל הקודים זמין בעמוד Meta Error Codes.

"statuses": [{
  "id": "wamid.HBgLMTY1...",
  "status": "failed",
  "timestamp": "1711200005",
  "recipient_id": "972520000000",
  "errors": [{
    "code": 131026,
    "title": "Message Undeliverable",
    "message": "Message Undeliverable.",
    "error_data": {
      "details": "Receiver is incapable of receiving this message"
    }
  }]
}]

להלן שגיאות המסירה הנפוצות ביותר בחנויות איקומרס:

• קוד 131026 (Message Undeliverable): שגיאה זו מעידה על כך שהמספר אינו רשום בוואטסאפ, שהמשתמש חסם את המספר העסקי, או שמדיניות האבטחה של Meta מנעה את המסירה. אין לנסות שליחה חוזרת באופן אוטומטי למספר זה.
• קוד 131047 (Re-engagement Required): ניסיון לשלוח הודעה רגילה (חופשית) מעבר לחלון 24 השעות מההודעה האחרונה של המשתמש. הפתרון הוא שליחת תבנית מאושרת (Template Message) בלבד.
• קוד 130429 (Rate Limit Exceeded): חריגה מקצב השליחה המותר לחשבון. במקרה זה יש לעצור את התור ולהכניס מנגנון Retry הדרגתי (Exponential Backoff).

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

שיפור שירות הלקוחות בחנות בעזרת ניטור שגיאות פרואקטיבי

כשחנות מפעילה אינטגרציה כגון WhatsApp ל‑WooCommerce או WhatsApp ל‑Shopify, תקלות מסירה משפיעות ישירות על שביעות רצון הלקוח. לקוח שלא מקבל אישור הזמנה או מספר מעקב למשלוח מניח שההזמנה לא נקלטה, ופונה בבהילות למוקד התמיכה.

ניטור פרואקטיבי של סטטוס המסירה מאפשר להגדיר ארכיטקטורת עמידות:

1. נתיב גיבוי אוטומטי (Fallback): כאשר מתקבל סטטוס failed עבור הודעת עדכון הזמנה קריטית, המערכת שלכם מזהה את הכשל מיד ושולחת את העדכון כהודעת SMS קלאסית.
2. טיוב נתונים ב-CRM: זיהוי מספרים לא תקינים (קוד 131026) מאפשר לסמן את הלקוח ברשומות החנות, לעצור שליחת קמפיינים עתידיים לאותו יעד, ולמנוע פגיעה בדירוג האיכות (Quality Rating) של החשבון העסקי ב-Meta.
3. התראות לתמיכה: במקום להמתין לפניית הלקוח, המערכת פותחת כרטיס שירות פנימי ברגע שהודעת משלוח נכשלת, ומאפשרת לנציג ליצור קשר חלופי עם הלקוח מבעוד מועד.

ארכיטקטורת ניטור אמינה: איך לבנות תשתית Webhooks עמידה

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

1. אישור מהיר ושחרור השרת: שרתי Meta מצפים לתגובת HTTP 200 OK תוך מספר שניות בודדות. אין לבצע עיבודים כבדים, שאילתות מסד נתונים מורכבות או קריאות API חיצוניות בתוך מחזור הבקשה. השרת צריך לקלוט את ה-Payload, להכניס אותו לתור פנימי (כגון Redis או RabbitMQ), ולהחזיר מיד סטטוס 200.
2. אידמפוטנטיות (Idempotency): רשתות תקשורת שולחות לעיתים בקשות חוזרות. המערכת חייבת לשמור את צמד הנתונים wamid ו-status, ולוודא שאירוע זהה שכבר טופל לא יפעיל לוגיקה עסקית פעם נוספת.
3. אימות מקור הבקשה: כדי להבטיח שהבקשה הגיעה בוודאות מ-Meta ולא מגורם עוין, יש לאמת את החתימה הדיגיטלית שנשלחת בכותרת X-Hub-Signature-256 באמצעות ה-App Secret של האפליקציה שלכם.

צוות המומחים של Wagate מסייע למותגי מסחר וסוכנויות לבנות, לייעל ולנטר תשתיות מסרים מבוססות Meta Cloud API בהיקפים גבוהים. אם אתם מעוניינים לבחון את תשתית התקשורת שלכם או לחבר את החנות לפתרון אוטומציה יציב, צרו קשר עם Wagate לקבלת ליווי טכני מותאם.

שאלות נפוצות

למה הודעה נשארת בסטטוס sent ולא עוברת ל-delivered?

הודעה נשארת במצב sent כאשר שרתי Meta העבירו אותה בהצלחה הלאה, אך היא טרם הגיעה למכשיר הנמען. הדבר מתרחש כאשר הטלפון של הלקוח כבוי, אינו מחובר לאינטרנט, נמצא במצב טיסה או שכרטיס ה-SIM אינו פעיל. שרתי WhatsApp מנסים למסור את ההודעה עד 30 יום לפני שמחזור החיים שלה פג.

האם ניתן לדעת בוודאות אם לקוח קרא את ההודעה אם ביטל אישורי קריאה?

לא. כאשר משתמש מבטל את אפשרות אישורי הקריאה בהגדרות הפרטיות של וואטסאפ, Meta אינה משדרת אירועי read ל-Webhook עבור הודעות אישיות שנשלחות אליו. במקרה זה, הסטטוס הגבוה ביותר שתקבלו יהיה delivered, אלא אם המשתמש ישיב להודעה באופן אקטיבי ובכך יאשר את קריאתה.

מה ההבדל בין קוד שגיאה 131026 לבין כשלים זמניים ב-Meta API?

קוד 131026 מעיד על כשל קבוע במסירה (כגון מספר שאינו קיים בוואטסאפ או חסימת המספר העסקי על ידי המשתמש), ולכן אין לנסות שליחה חוזרת לאותו יעד. לעומת זאת, כשלים זמניים, כמו קוד 130429 המציין חריגה ממגבלות קצב, דורשים שהייה קצרה ושליחה מחדש באמצעות מנגנון השהיה הדרגתי.

מדוע אירועי Webhook מגיעים לפעמים בסדר כרונולוגי הפוך?

שרתי Meta פועלים בארכיטקטורה מבוזרת בקנה מידה גלובלי. ניתוב אירועים דרך שרתים שונים וזמני השהיית רשת משתנים עלולים לגרום לכך שאירוע read ייקלט בשרת שלכם כמה מילישניות לפני אירוע ה-delivered. לכן יש לתכנן מנגנון בדיקת סטטוס במערכת המונע דריסת מצב מתקדם על ידי מצב קודם.