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

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

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

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

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

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

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

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

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

הבדיקה:

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'])))"

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'));

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
$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);

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

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

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

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

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

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

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

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

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

3. שורה אחת בדיוק לכל דגל. כשיש כמה שורות עם אותו Name, אחת מההקמה ואחת מאיפוס מאוחר יותר, השורה הישנה תמיד מנצחת: שורה ישנה עם false מסתירה שורה חדשה עם true.

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

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"}'

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();

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
$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.

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

Permission denied for action find on class Accounts

שלושה פרטים שמקשים על האבחון:

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

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

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

[
  { "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 תמיד יוצר שורה חדשה (כפילות מסומנת בסטטוס “ליד כפול”, לא ממוזגת).

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

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

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

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

{"code":102,"error":"Invalid parameter for query: X"} = הפרמטר אינו נתמך בפריסה הזו (distinct, readPreference). where שאינו JSON תקין מחזיר דווקא 500; קודדו אותו ל‑URL. ראו שאילתות.

פונקציות אינן מתחת ל‑/parse; שם כל שם מחזיר {"code":141,"error":"function not found"}:

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

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

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

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

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