שגיאת WhatsApp 131005: הגישה נדחתה, חסרה הרשאה
שגיאה 131005 אומרת שלאסימון הגישה (Access Token) חסרה הרשאה שנקודת הקצה של WhatsApp דורשת, כי היא מעולם לא ניתנה או שהוסרה בהמשך. התיאור של Meta הוא "Permission is either not granted or has been removed." והתיקון הוא לבדוק את האסימון בכלי ניפוי האסימונים (Access Token Debugger), ואז להעניק את ההרשאה החסרה או לעבור לאסימון שיש לו אותה.
הקוד של Meta עבור "Permission is either not granted or has been removed."
ההרשאה הדרושה כדי לשלוח כל סוג של הודעה למשתמשי WhatsApp
שלוש ההרשאות business_management, whatsapp_business_management, whatsapp_business_messaging מוקצות יחד בעת יצירת אסימון של משתמש מערכת.
מה המשמעות של שגיאת WhatsApp 131005?
המשמעות היא שהאסימון מתקבל כאסימון אמיתי, אבל אין בו ההרשאה שנקודת הקצה בודקת.
המסמכים של Cloud API מ-Meta מפרטים את 131005 עם הטקסט "Permission is either not granted or has been removed." באותו משפט בדיוק משתמשת גם שגיאה 10 של Graph API. ההבדל הוא רק בטווח: 10 הוא קוד כללי של Graph API, ואילו 131005 שייך לקודי WhatsApp, אלה שמתחילים ב-131, ולכן הוא ספציפי יותר.
מכיוון שהניסוח זהה, האבחון זהה. התיקון ש-Meta ממליצה עליו בשני המקרים: להשתמש בכלי ניפוי האסימונים ולוודא שלאפליקציה יש את ההרשאות שנקודת הקצה דורשת.
איזו הרשאה חסרה בדרך כלל?
בדרך כלל אחת משתי ההרשאות של WhatsApp, והבחירה תלויה במה שהקריאה עושה.
מדריך ההרשאות של Meta מחלק אותן לפי תפקיד. ההרשאה whatsapp_business_messaging נדרשת לשליחת כל סוג של הודעה ולקבלת וובהוקים (Webhook) של הודעות וסטטוס. ההרשאה whatsapp_business_management נדרשת למטא-דאטה של החשבון, ניהול תבניות, רשימת מספרי טלפון, נתוני ניתוח ווובהוקים של החשבון.
אסימון שנוצר רק עם הרשאת הניהול יכול לקרוא את החשבון ולרשום תבניות, ואז להיכשל ברגע שהוא מנסה לשלוח. כשיוצרים אסימון של משתמש מערכת, המדריך של Meta לאסימוני גישה מורה להקצות יחד שלוש הרשאות (business_management, whatsapp_business_management, whatsapp_business_messaging) ולא להסתפק בחלקן.
איך מתקנים את שגיאה 131005?
קודם קוראים את האסימון, ואז משנים רק את מה שחסר.
קוראים לנקודת הקצה debug_token, או מדביקים את האסימון בכלי ניפוי האסימונים. המאפיין scopes מפרט כל הרשאה שניתנה. משווים אותו לדף ההפניה של נקודת הקצה שנכשלה.
אם הרשאה חסרה, יוצרים אסימון חדש שכולל אותה, או מבקשים מבעל העסק להעניק אותה שוב כשהאסימון מגיע מתהליך של שותף. אם כל ההרשאות קיימות והשגיאה נמשכת, בודקים שמשתמש המערכת שמאחורי האסימון קיבל גישה ל-WhatsApp Business Account הספציפי, כי אסימון יכול להכיל את כל ההרשאות ועדיין לא להיות מוקצה לנכס הזה.
טעויות נפוצות
- להניח שהאסימון פג תוקף. פקיעת תוקף מחזירה 190 או 0. הקוד הזה אומר שהאסימון עובד אבל חסרה לו הרשאה.
- ליצור אסימון עם הרשאת ניהול בלבד ולהשתמש בו לשליחה. שליחה דורשת את ההרשאה whatsapp_business_messaging, ולא רק את הרשאת הניהול.
- לבדוק את ההרשאות ולעצור שם. משתמש מערכת צריך גם גישה ל-WhatsApp Business Account הספציפי.
EasyCoexistence מחברת כל מספר דרך Embedded Signup של Meta, שבו העסק מעניק לאפליקציה את ההרשאות שלה, ושרת ה-MCP שלה מדווח על תקינות החיבור של מספר, כך שעוזר יכול לבדוק לפני שליחה.
שאלות נפוצות
האם 131005 היא אותה שגיאה כמו 10?
לשתיהן אותו תיאור במסמכי Meta. 131005 שייכת לטווח של WhatsApp, ואילו 10 שייכת ל-Graph API, הטווח הכללי.
האם אפשר להסיר הרשאה אחרי ההגדרה?
כן. התיאור של Meta מכסה במפורש הרשאות שהוסרו, לא רק הרשאות שמעולם לא ניתנו.
האם שגיאה 131005 משפיעה על אפליקציית WhatsApp Business בטלפון?
לא. היא נוגעת לאסימון ה-API בלבד. האפליקציה בטלפון ממשיכה לעבוד כרגיל.
האם לנסות שוב אחרי שגיאה 131005?
לא. ניסיון חוזר עם אותו אסימון מניב אותה תוצאה. קודם מתקנים את ההרשאה.
המשיכו לקרוא
מוכנים להתחיל?
מגדירים WhatsApp Coexistence בתוך דקות, לא חודשים. האפליקציה ממשיכה לעבוד בטלפון.
התחילו תקופת ניסיון בחינםנבדק ב-