שגיאות ופתרון תקלות

תבנית השגיאה

רוב הכישלונות מוחזרים כ‑4xx עם גוף JSON שמכיל code ו‑error:

JSON

{ "code": 105, "error": "Invalid field name: bl!ng." }

שני חריגים לתבנית

• where שאינו JSON תקין מוחזר כ‑500 עם {"code":1,"message":"Internal server error."} — שימו לב, message ולא error.
• $text על שדה בלי אינדקס טקסט מוחזר כ‑500, והפעם error הוא אובייקט — השגיאה הגולמית של מנוע הנתונים: {"code":1,"error":{"ok":0,"code":27,"codeName":"IndexNotFound",…}}.

קוד שמנתח שגיאות חייב לסבול את שלוש הצורות (error מחרוזת, message מחרוזת, error אובייקט). ראו core-api-06.

אבל לא כל כישלון מגיע כ‑4xx

שלושת התסמינים היקרים ביותר במוצר הזה מחזירים 200:

1. כתיבה בשכבת הטפסים שהשדה שלה לא נשמר,
2. פרטי גישה שגויים בשכבת ה‑MCP,
3. batch שבו חלק מהפעולות נכשלו.

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

הקודים שתפגשו בפועל

קוד	ההודעה	מה זה אומר	מה עושים
101	Object not found.	ה‑objectId לא קיים, או שההרשאות מסתירות אותו	ודאו 10 תווים ואת הטבלה הנכונה; בדקו הרשאות טבלה
101	Invalid username/password. · User is not active.	כשל התחברות — סיסמה שגויה, או active:false	ראו משתמשים
102	Invalid parameter for query: <name>	פרמטר שאילתה שאינו נתמך — distinct, readPreference, match…	הסירו אותו; ראו שאילתות
105	Invalid field name: bl!ng.	תו לא חוקי בשם שדה	שמות שדות: אותיות/ספרות/קו תחתון, ללא רווחים ותווים מיוחדים
107	cannot route batch path /classes/X	נתיב ב‑batch בלי הקידומת /parse	ראו batch
111	schema mismatch for <Table>.<Field>; expected <X> but got <Y>	טיפוס לא תואם — Pointer או Date שנשלחו כמחרוזת	עטפו לפי סוגי נתונים
119	This action is not allowed without a valid CAPTCHA	ניסיון כתיבה אנונימית ישירה ל‑REST	ראו הסעיף הייעודי למטה. אל תפתחו הרשאות — זה לא עוזר
119	Permission denied for action <find/update> on class <X>	פרטי גישה שגויים, או משתמש בלי תפקיד	אותו קוד, בעיה אחרת לגמרי — קראו את ההודעה
119	Pointer to Object <id> exists in table <T> in key <F>. Delete is not allowed.	מחיקה של רשומה שמישהו מצביע עליה — כולל טבלאות מערכת: משתמש שהתחבר או כתב דרך ה‑API מוצבע מ‑_RequestLog.user, ו‑DELETE /parse/users/<id> נחסם (api-c-02)	מחקו קודם את הילדים, או נתקו את הקישור. למשתמשים — העדיפו active: false על פני מחיקה
142	Password does not meet the Password Policy requirements.	סיסמה שאינה עומדת במדיניות	8 תווים, אות קטנה, גדולה וספרה
202	Account already exists for this username.	הרשמת משתמש עם username קיים	username הוא ייחודי; חפשו לפני יצירה — משתמשים
206	Cannot modify user <id>.	משתמש מנסה לעדכן משתמש אחר	עדכון משתמשים דורש Master Key
209	invalid session token	הסשן פג או בוטל	התחברו מחדש ונסו פעם אחת נוספת — משתמשים
400	{"error":"AcceptWebToTable is Disabled"} · AcceptWebToCaseLeads is Disabled	דגל ה‑Config של הטופס כבוי. שימו לב: HTTP 400, ובלי שדה code	ראו “הטופס מחזיר … is Disabled” למטה
400	{"error":"User function not found"}	שם פונקציה שאינו קיים בנתיב /functions/{appId}/… — למשל השם הישן web2lead (הפונקציה נקראת getlead)	בדקו את שם הפונקציה; ראו getlead
403	Invalid file type	סוג הקובץ בהעלאה אינו נתמך, או שהתוכן אינו תואם לסיומת	ראו קבצים
403	unauthorized: master key is required	פעולה שדורשת Master Key או API Key — מחיקת קובץ, קריאת סכימה. גם Session Token של ה‑owner מקבל 403 על סכימה; API Key קורא	הוסיפו אישור מתאים
400	{"error":"missing \"phone\""} / {"error":"missing \"table\" in request body"}	חסר שדה חובה בטופס. HTTP 400 (לא 422), בלי שדה code	ראו web2table
500	server error	where פגום (או # לא מקודד בערך), $text בלי אינדקס, או תקלה אמיתית	שמרו את הזמן המדויק ואת גוף הבקשה ופנו לתמיכה

---

אבחון לפי תסמין

“הבקשה מחזירה 200 אבל השדה נשאר ריק”

התסמין הנפוץ ביותר בכל האינטגרציות, ויש לו שני מקורות.

א. שלחתם Pointer בעטיפת Parse בשדה table_* של web2table.

JavaScript

// ✘ לא נכון בשדה table_* של web2table
{ "table_CourseId": { "__type": "Pointer", "className": "Courses", "objectId": "aB3dEf9HiJ" } }

// ✔ נכון — מחרוזת objectId חשופה, 10 תווים
{ "table_CourseId": "aB3dEf9HiJ" }

התקלה הזו ממוקדת: בשדות table_* של web2table הערך העטוף נזרק בשקט, וכך גם מזהה שאורכו שונה מ‑10 תווים (start-b-01, forms-b-02). בשדות account_* של web2table, וכן ב‑getlead, הצורה העטופה {"__type":"Pointer",…} דווקא נקלטת ונשמרת (אומת 24.08.2026), ושם המלכודת היא אורך מזהה שגוי, שמפיל את כל הבקשה ב‑400. מחרוזת objectId חשופה באורך 10 עובדת בכל המקרים, ולכן זו הצורה שכדאי לכתוב בה קוד. תאריכים סלחניים: גם מחרוזת ISO שטוחה, גם YYYY-MM-DD וגם {"__type":"Date","iso":…} נשמרו כראוי.

טבלת ההמרה המלאה בין שלוש השכבות: סוגי נתונים.

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

הבדיקה:

Bash

curl -sS "https://api.mbapps.co.il/parse/schemas/Accounts" \
  -H "X-Parse-Application-Id: $APP_ID" -H "X-Parse-API-Key: $API_KEY" \
  | python -c "import sys,json;print('\n'.join(sorted(json.load(sys.stdin)['fields'])))"

JavaScript

const APP_ID = process.env.APP_ID, API_KEY = process.env.API_KEY;

const res = await fetch('https://api.mbapps.co.il/parse/schemas/Accounts', {
  headers: {
    'X-Parse-Application-Id': APP_ID,
    'X-Parse-API-Key': API_KEY,
  },
});
const schema = await res.json();
console.log(Object.keys(schema.fields).sort().join('\n'));

Python

import os, requests

APP_ID = os.environ["APP_ID"]
API_KEY = os.environ["API_KEY"]

res = requests.get(
    "https://api.mbapps.co.il/parse/schemas/Accounts",
    headers={
        "X-Parse-Application-Id": APP_ID,
        "X-Parse-API-Key": API_KEY,
    },
)
print("\n".join(sorted(res.json()["fields"])))

PHP

<?php
$appId = getenv('APP_ID');
$apiKey = getenv('API_KEY');

$ch = curl_init();
curl_setopt_array($ch, [
    CURLOPT_URL => "https://api.mbapps.co.il/parse/schemas/Accounts",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER => [
        "X-Parse-Application-Id: $appId",
        "X-Parse-API-Key: $apiKey",
    ],
]);
$response = curl_exec($ch);
curl_close($ch);
$schema = json_decode($response, true);
$fields = array_keys($schema["fields"]);
sort($fields);
echo implode("\n", $fields);

הבדיקה שתופסת את שניהם

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

“אני מקבל 119 — CAPTCHA — על כתיבה מהאתר”

JSON

{ "code": 119, "error": "This action is not allowed without a valid CAPTCHA" }

זה קורה כשקוד אנונימי — בלי Session Token ובלי Master Key, רק עם X-Parse-Application-Id — מנסה לכתוב ישירות ל‑/parse/classes/<Table>.

פתיחת ההרשאות לא תפתור את זה — והיא תפגע בכם

זה אומת בסביבה חיה, פעמיים: כתיבה אנונימית נדחית עם 119 גם אחרי שהרשאת הטבלה נפתחה ל‑create: {"*": true} מלא.

שער ה‑CAPTCHA יושב לפני בדיקת ההרשאות. לכן פתיחת ההרשאות אינה קונה כלום מבחינת הכתיבה — אבל היא כן פותחת את הקריאה: באותה בדיקה, find: {"*": true} איפשר לקורא אנונימי לשלוף את כל הטבלה. כלומר מי ש“מתקן” 119 בפתיחת CLP חשף את הנתונים לעולם ועדיין לא קיבל את הכתיבה שרצה.

המסלול הנכון לכתיבה אנונימית הוא פונקציות הטפסים: web2table ו‑getlead. הן פונקציות צד שרת שרצות עם הרשאות מלאות, מבצעות ולידציה משלהן, ולכן טבלת היעד יכולה — וצריכה — להישאר סגורה.

הערת שם

בחומרים ישנים getlead נקראת “web2lead” — שם שאינו רשום בשרת ומחזיר 400 {"error":"User function not found"}. getlead אומתה בפועל (24.08.2026).

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

העובדה	ההשלכה
כתיבה אנונימית ישירה חסומה ב‑CAPTCHA	אין דרך לעקוף בהגדרות
web2table רצה מוגברת ועוקפת הרשאות טבלה	השאירו את ה‑CLP של טבלת היעד סגור
web2table היא יצירה בלבד	אין מסלול עדכון אנונימי כלל

ו“עדכון מקישור ציבורי”? רק בדפוס טבלת קליטה + טריגר הקרנה: העמוד הציבורי יוצר שורה בטבלת קליטה ייעודית, וטריגר מקרין את הערכים על הרשומה העסקית. פירוט: web2table.

“הטופס מחזיר … is Disabled”

בקריאה הראשונה אחרי הטמעה, 400 {"error":"AcceptWebToTable is Disabled"} הוא כמעט תמיד דגל ה‑Config — לא הקוד. (הסטטוס הוא 400, לא 403 — אומת על web2case עם הדגל כבוי.)

1. בדקו את הדגל הנכון. ל‑getlead יש AcceptWebLeads; ל‑web2table יש AcceptWebToTable; ל‑web2case / web2sale יש AcceptWebToCaseLeads / AcceptWebToSaleLeads. הם דגלים נפרדים — דגל אחד דלוק לא מפעיל את השני.

2. הערך חייב להיות אובייקט, לא בוליאני חשוף — הסכימה אוכפת זאת: Value: true נדחה ב‑111 schema mismatch for Config.Value; expected Object but got Boolean:

   JSON

   { "Name": "AcceptWebToTable", "Value": { "AcceptWebToTable": true } }

3. שורה אחת בדיוק לכל דגל. אם יש כמה שורות עם אותו Name — וזה קורה בפועל, אחת מההקמה ואחת מאיפוס מאוחר יותר — השורה הישנה תמיד מנצחת (דטרמיניסטי): שורה ישנה עם false מסתירה שורה חדשה עם true (ראו web-forms-09).

בדיקה ותיקון (Master Key, API Key או Session Token של משתמש מורשה — ראו ההערה למטה):

Bash

curl -sS -G "https://api.mbapps.co.il/parse/classes/Config" \
  -H "X-Parse-Application-Id: $APP_ID" -H "X-Parse-Master-Key: $MASTER_KEY" \
  --data-urlencode 'where={"Name":"AcceptWebToTable"}'

JavaScript

const APP_ID = process.env.APP_ID, MASTER_KEY = process.env.MASTER_KEY;

const params = new URLSearchParams({
  where: '{"Name":"AcceptWebToTable"}',
});

const res = await fetch(`https://api.mbapps.co.il/parse/classes/Config?${params}`, {
  headers: {
    'X-Parse-Application-Id': APP_ID,
    'X-Parse-Master-Key': MASTER_KEY,
  },
});
const data = await res.json();

Python

import os, requests

APP_ID = os.environ["APP_ID"]
MASTER_KEY = os.environ["MASTER_KEY"]

res = requests.get(
    "https://api.mbapps.co.il/parse/classes/Config",
    headers={
        "X-Parse-Application-Id": APP_ID,
        "X-Parse-Master-Key": MASTER_KEY,
    },
    params={
        "where": '{"Name":"AcceptWebToTable"}',
    },
)
data = res.json()

PHP

<?php
$appId = getenv('APP_ID');
$masterKey = getenv('MASTER_KEY');

$query = http_build_query([
    'where' => '{"Name":"AcceptWebToTable"}',
]);

$ch = curl_init();
curl_setopt_array($ch, [
    CURLOPT_URL => "https://api.mbapps.co.il/parse/classes/Config?$query",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER => [
        "X-Parse-Application-Id: $appId",
        "X-Parse-Master-Key: $masterKey",
    ],
]);
$response = curl_exec($ch);
curl_close($ch);
$data = json_decode($response, true);

אבחון דגל כבוי — MCP נפתח ב‑25.08.2026

בשרת מלפני 25.08.2026 טבלת Config חסומה מכלי ה‑MCP (Error: Table is restricted) וסוכן AI לא יכול לאשר או להפריך את הדגל; מאז 25.08.2026 היא נגישה גם מ‑MCP בחיבור Master Key (אומת 2026-08-25; web-forms-07). מסלולים נוספים: סביבת הפיתוח — סביבת פיתוח ← Databases ← DB For MyBusiness ← Tables ← Config — או REST. ב‑REST, בניגוד למה שנהוג לחשוב, לא נדרש Master Key: גם API Key וגם Session Token של ה‑owner קוראים את הטבלה (אומת); משתמש בלי תפקיד וקורא אנונימי מקבלים 119 Permission denied for action find on class Config.

“אני מקבל 200 אבל ‘Permission denied’ בתוך התשובה”

זו החתימה של שכבת ה‑MCP, והמלכודת המסוכנת ביותר בכל התיעוד הזה.

פרטי גישה שגויים בשכבת ה‑MCP אינם מייצרים שגיאת HTTP. הקריאה חוזרת 200, והשגיאה יושבת בתוך תשובת הכלי:

Permission denied for action find on class Accounts

שלושה פרטים שהופכים את זה לקשה לאבחון:

מה קורה	למה זה מבלבל
פרטי גישה שגויים → 200 + הודעה בגוף	אין שום סימן בשכבת ה‑HTTP
כותרת אימות חסרה → HTTP 403 עם שגיאת JSON‑RPC {"code":-32000,"message":"Authorization header is required"}	שני מצבי כשל שונים לחלוטין לאותה בעיה לכאורה
initialize ו‑tools/list מצליחות בלי אימות	הלקוח נראה “מחובר” ונכשל רק בקריאת הנתונים הראשונה

בנוסף — המפתח תקף רק תחת שם הכותרת שלו. אותו ערך שהודבק ב‑X-Parse-Master-Key במקום ב‑X-Parse-API-Key (או להפך) נחשב לפרטי גישה שגויים, כלומר: 200 עם Permission denied (אומת בשני הכיוונים).

כלל האבחון

אבחנו מהתשובה של כלי נתונים — לא מקוד הסטטוס, לא מנורית “מחובר”, ולא מהעובדה שרשימת הכלים נטענה.

בדיקת השפיות: הריצו קריאת קריאה פשוטה על טבלה אמיתית (למשל ספירת רשומות ב‑Accounts). אם היא מחזירה נתונים — החיבור באמת עובד.

ראו שרת ה‑MCP ו‑אימות והרשאות.

“batch החזיר 200 ובכל זאת רשומות חסרות”

ב‑POST /parse/batch, כישלון של פריט בודד לא מפיל את הבקשה ולא משנה את קוד הסטטוס. התשובה היא מערך שבו כל איבר הוא success או error בנפרד:

JSON

[
  { "success": { "objectId": "aB3dEf9HiJ" } },
  { "error":   { "code": 101, "error": "Object not found." } }
]

קוד שבודק רק response.ok יאבד רשומות בשקט. חובה לעבור על כל איבר. ראו batch.

שתי הערות מהאימות: כישלון של POST/PUT/DELETE בתוך batch מגיע בצורה המוכרת (code + error, למשל 101 או 105); ואילו פריט GET בתוך batch אינו נתמך — הוא מחזיר {"error":{"error":"Cannot convert undefined or null to object"}} בלי code, גם על רשומה קיימת. batch הוא לכתיבה בלבד.

“יצרתי איש קשר וקיבלתי כפילות”

• ב‑web2table: שלחו את הטלפון במפתח phone (בלי קידומת account_). account_PhoneNumber נשמר לשדה אבל לא מזין את זיהוי הכפילויות. הפורמט עצמו סלחני — 0500000032 ו‑+972500000032 אותרו כאותו איש קשר (אומת).
• ב‑REST: אין אכיפת ייחודיות בפלטפורמה. חובה חיפוש‑לפני‑יצירה מצדכם — ראו הזרימה הקנונית.
• טלפונים ישראליים חיים בכמה פורמטים באותה טבלה. חיפוש על פורמט אחד יחמיץ את השאר — דפוס ה‑$or.
• getlead תמיד יוצר שורה חדשה (כפילות מסומנת בסטטוס “ליד כפול”, לא ממוזגת) — אומת בפועל (24.08.2026).

“עדכנתי איש קשר קיים דרך הטופס — ושום דבר לא השתנה”

זה מתוכנן. ב‑web2table, שדות account_* מוחלים רק כשנוצר איש קשר חדש; איש קשר קיים מקושר לרשומה החדשה ולא מעודכן. עדכון של איש קשר קיים דורש REST.

“שינוי דרך ה‑API הפעיל התראות ללקוחות”

כל כתיבה — כולל דרך Master Key — מפעילה טריגרים מסוג data change. בטעינות המוניות זה מתפוצץ למאות מיילים או הודעות WhatsApp.

• לפני טעינה: תאמו עם בעל האוטומציות.
• ל‑POST /parse/batch אין דגל השתקה — skipTriggers: true ברמת הבקשה פשוט מתעלמים ממנו (אומת: השרשרת רצה במלואה).
• בכלי ה‑MCP Create-Many יש skipTriggers: true (Master Key בלבד), והוא עובד — אומת: הרשומה נוצרה ואף טריגר לא רץ. (עד 23.08.2026 הכלי דרש מפתח מדומה "fieldName": null בכל אובייקט — core-api-02 / mcp-data-01; נסגר בשרת באותו יום.)
• שרשרת טריגרים מוגבלת ל‑3 רמות — אבל כל רשומה עדיין מפעילה את הרמה הראשונה. חריגה נרשמת ב‑_syslogTriggers.error כ‑blocked! trigger step is to deep -3. source trigger: <triggerId> (כך, עם שגיאת הכתיב; אומת על שרשרת בת 5 טבלאות — הרמה הרביעית לא נוצרה).

ראו מגבלות ומכסות.

“הבקשה חוזרת 400”

קראו את הגוף — הוא כמעט תמיד מסביר. {"code":102,"error":"Invalid parameter for query: X"} אומר שהפרמטר אינו נתמך בפריסה הזו (distinct ו‑readPreference, למשל, אינם). where שאינו JSON תקין מחזיר דווקא 500. ובכל מקרה — קודדו את where ל‑URL: --data-urlencode (curl), params (requests), URLSearchParams (JS). ראו שאילתות.

“השאילתה מחזירה מערך ריק, בלי שגיאה”

הסיבה	התיקון
שם הטבלה שגוי	טבלה שאינה קיימת מחזירה 200 ומערך ריק. אמתו מול GET /parse/schemas/<Table> — הוא יחזיר 400 אם המחלקה לא מוגדרת
סינון Pointer במחרוזת חשופה	שלחו את האובייקט המלא {"__type":"Pointer",…}
סינון תאריך במחרוזת שטוחה	ב‑where תאריך הוא {"__type":"Date","iso":…}
ערך ב‑where שמכיל + בלי קידוד	+ הופך לרווח — השאילתה מחזירה [] בשקט. (& לא מקודד מחזיר 400 102 Invalid parameter for query; # לא מקודד מחזיר 500.) קודדו תמיד
objectId שאינו 10 תווים	ודאו אורך; אולי הדבקתם מזהה 24‑hex של עמוד
הרשאות מסתירות את הרשומה	נסו עם Master Key כבדיקת אבחון בלבד
הערך פשוט לא קיים	ספרו: limit=0&count=1

“פונקציית השרת לא נמצאת”

בדקו את הנתיב. פונקציות אינן מתחת ל‑/parse — שם תקבלו {"code":141,"error":"function not found"} לכל שם:

✘ https://api.mbapps.co.il/parse/functions/getlead
✔ https://api.mbapps.co.il/functions/{appId}/getlead

ה‑appId יושב בנתיב, לא רק בכותרת. ראו פונקציות צד שרת.

ובנתיב הנכון, שם פונקציה שאינו קיים מחזיר 400 {"error":"User function not found"} (בלי code). זו למשל התשובה לשם הישן web2lead — הפונקציה נקראת getlead.

“המשתמש לא מצליח להתחבר / לא רואה כלום”

הסימפטום	מה חסר
לא מצליח להתחבר	חבילת רישוי (מושב), או active: false
מתחבר ורואה טבלאות ריקות	תפקיד, או הרשאות הטבלה (CLP)
טבלה חדשה — “השדות ריקים”	טבלה חדשה נולדת חסרת הרשאות
רואה רשומות של אחרים	חסר סינון ברמת שורה

ראו משתמשים ו‑סביבות וגישה.

---

איפה מסתכלים כשצריך ראיות

מה קרה	איפה מתועד
שינוי בנתונים	_Timeline — סינון לפי objectIdValue + objectClass
ריצת אוטומציה	_syslogTriggers — שדה error
הודעת WhatsApp	ConversationMessages · _syslogCampaignWA
SMS	SMS (עסקי) · _syslogSMS (ספק)
מייל	Emails — SendStatus, ErrorMessage

המדריך המלא, כולל מתכוני חקירה: יומנים וראיות.

שלוש הסתייגויות על ראיות

• ציר הזמן הוא opt‑in לכל טבלה. רק 11 טבלאות מגיעות איתו דלוק, והפעלה אינה משלימה לאחור. לטבלה שלא נוטרה פשוט אין נתונים.
• _syslogTriggers אינו מובטח שיאוכלס בכל סביבה. היעדר שורה אינו הוכחה שהטריגר לא רץ. וכשיש שורה — error ו‑data הם JSON עם HTML entities (" במקום "), ראו api-c-04.
• _RequestLog רושם כתיבות בלבד. GET על /parse/classes/… אינו נרשם, הרישום אסינכרוני, ובמערכת חדשה המחלקה עלולה לא להיראות ב‑REST עד שהסכימה נרשמת — ראו api-c-01 (מחליף את core-api-07). “האם הקריאה שלי הגיעה לשרת” נענה רק לכתיבות.

עדיין תקוע?

צרפו לפנייה: הזמן המדויק (עם אזור זמן), ה‑Application Id, נקודת הקצה, גוף הבקשה בלי סודות, וקוד הסטטוס עם גוף התשובה המלא — support@mybusiness-crm.com.