שגיאה 10 ב-WhatsApp: ההרשאה לא ניתנה או שהוסרה
קוד שגיאה 10 אומר שלאסימון גישה (Access Token) של האפליקציה חסרה הרשאה שנקודת הקצה דורשת, או כי היא מעולם לא ניתנה או כי היא הוסרה. התיאור של Meta הוא "Permission is either not granted or has been removed." Meta מציינת גם שתי סיבות ספציפיות ל-WhatsApp: מספר שלא נמצא ברשימת ההיתרים ב-Flows with Endpoint, ואי עמידה בדרישות הזכאות של ממשק API מסוים.
הקוד של Meta עבור "Permission is either not granted or has been removed."
השם שמדריך הטיפול בשגיאות של Graph API נותן לקוד 10.
מה שאפליקציית שותף צריכה לכל הרשאה שהיא משתמשת בה בחשבונות של לקוחות.
מה המשמעות של קוד שגיאה 10 ב-WhatsApp?
המשמעות היא שהאסימון הגיע ל-Meta וזוהה, אבל ההרשאה שהקריאה דורשת לא נמצאת עליו.
ב-Cloud API reference של Meta מופיע לקוד 10 הטקסט "Permission is either not granted or has been removed." מדריך הטיפול בשגיאות של Graph API קורא לו API Permission Denied ואומר לטפל בהרשאה החסרה.
המילה "הוסרה" חשובה. הרשאה יכולה להינתן בזמן ההגדרה ולהילקח בהמשך, למשל כשמישהו מבטל את הגישה של האפליקציה ב-Business Settings. לכן אינטגרציה שעבדה חודשים יכולה להתחיל להחזיר 10 בלי שום שינוי בקוד שלה.
אילו סיבות נוספות Meta מציינת לשגיאה 10?
שתיים שספציפיות ל-WhatsApp, ושתיהן קל לפספס כי הן לא קשורות להרשאות (scopes) בכלל.
ב-WhatsApp Flows with Endpoint, Meta אומרת לוודא שהמספר ששימש להגדרת המפתח הציבורי של העסק נמצא ברשימת ההיתרים. מספר שנמצא מחוץ לרשימה מחזיר את הקוד הזה גם כשהאסימון כולל את כל ההרשאות.
Meta אומרת גם שחשבון שאינו עומד בדרישות הזכאות של ממשק API שהוא קורא לו מקבל את הקוד הזה. במקרה כזה שום שינוי באסימון לא יעזור, כי החסם הוא הזכאות של החשבון ולא האישור עצמו.
איך מתקנים שגיאה 10?
מתחילים ב-debugger של אסימון הגישה, שאותו Meta מציינת כבדיקה הראשונה.
אם ברשימת ה-scopes חסרה ההרשאה שנקודת הקצה צריכה, מבקשים מהעסק לתת אותה מחדש. באפליקציית שותף זה כולל גם אימות של Advanced access להרשאה, כי מדריך ההרשאות של Meta דורש אותו עבור חשבונות של לקוחות.
אם רשימת ה-scopes נראית מלאה, עוברים לשתי הסיבות הייחודיות ל-WhatsApp. בקריאת Flows בודקים את רשימת ההיתרים עבור המספר שהגדיר את המפתח הציבורי. בכל מקרה אחר קוראים את דרישות הזכאות של ממשק ה-API שאליו פונים, ומוודאים שהחשבון עומד בהן לפני ששינוי כלשהו נעשה באישורי הגישה.
טעויות נפוצות
- להניח שהאינטגרציה נשברה בגלל פריסה. הרשאה שהוסרה ב-Business Settings מחזירה את הקוד הזה בלי שום שינוי בקוד.
- לבנות מחדש את האסימון כשהסיבה היא זכאות. אסימון חדש לא יהפוך חשבון שאינו זכאי לזכאי.
- להתעלם מרשימת ההיתרים של Flows. ב-Flows with Endpoint מספר שמחוץ לרשימה מחזיר 10 גם כשכל ההרשאות קיימות.
EasyCoexistence ממשיכה לעקוב אחרי כל מספר מחובר גם אחרי ההצטרפות, כך שחיבור שאיבד גישה מופיע בלוח הבקרה במקום להתגלות קודם כשליחות שנכשלות.
שאלות נפוצות
האם שגיאה 10 זהה לשגיאה 131005?
יש להן אותו תיאור במסמכי Meta. קוד 10 הוא הקוד של Graph API, ו-131005 נמצא בטווח של WhatsApp. בודקים את שתיהן באותה דרך.
האם שגיאה 10 יכולה להופיע במספר שעבד אתמול?
כן. התיאור של Meta כולל הרשאות שהוסרו, ולכן גישה שניתנה קודם יכולה להישלל בהמשך.
האם שגיאה 10 אומרת שהאסימון פג תוקף?
לא. אסימון שפג תוקפו מחזיר קוד 190 או 0. קוד 10 אומר שהאסימון תקף אבל חסרה לו הרשאה.
איך רואים אילו הרשאות ניתנו?
קוראים ל-debug_token או פותחים את ה-debugger של אסימון הגישה. המאפיין scopes מציג כל הרשאה שנמצאת על האסימון.
המשיכו לקרוא
מוכנים להתחיל?
מגדירים WhatsApp Coexistence בתוך דקות, לא חודשים. האפליקציה ממשיכה לעבוד בטלפון.
התחילו תקופת ניסיון בחינםנבדק ב-