דלגו לתוכן

או התחילו מנקודה בטוחה: אינדקס הכלים המלא · מפת הטבלאות המרכזיות

מערכת חדשה — 14 יום חינם

הפעלת קליטה מהאתר — דגלי Config

עודכן 31.08.2026

נקודות הקצה של הטפסים כבויות עד שמדליקים אותן. עד אז כל בקשה חוזרת עם 400 {"error":"<שם הדגל> is Disabled"}, גם כשהקוד מושלם. זו הסיבה מספר אחת לשגיאה בקריאה הראשונה אחרי עלייה לאוויר.

ההפעלה היא שורה בטבלת המערכת Config: Name הוא מפתח החיפוש, ו‑Value הוא אובייקט שחוזר על אותו שם כמפתח פנימי.

Name (String) Value (Object) מה זה מפעיל
AcceptWebLeads { "AcceptWebLeads": true } getlead — נוצר אוטומטית בתבנית vanilla ודלוק כברירת מחדל
AcceptWebToTable { "AcceptWebToTable": true } web2table — יצירת שורה בטבלת יעד. אינו נוצר בתבנית, צריך להקים אותו
AcceptWebToCaseLeads { "AcceptWebToCaseLeads": true } web2case — יצירת פנייה
AcceptWebToSaleLeads { "AcceptWebToSaleLeads": true } קליטת web→sale‑lead. הדגל נקרא, אך אין בבילד הנוכחי שום פונקציה שמגיבה לו — קיים כנראה רק ב‑forks של לקוחות

המסלול הנתמך: כלי הנתונים של MCP בחיבור Master Key. הפתיחה של Config ל‑MCP מכוונת.

הכלי התשובה
Get-Data על Config כל שורות הטבלה, כולל שורות הדגלים ושורת Payment (רגיש)
Create-Data / Create-Many על Config יוצרים שורה ומחזירים objectId
Update-Data על שורת דגל עובד — זרימת “הדלקת הדגל” המלאה
Get-Schema על Config סכימה מלאה

תיאורי הכלים בסכימה גנריים ואינם מתעדים את הפתיחה, ו‑Get-Data מחזיר גם את שורת Payment על מבנה הסודות שלה. תוכן הטבלה רגיש, אל תדביקו אותו למסמכים.

עמוד Config בממשק ה‑CRM אין. /apps/MyBusiness/Config מחזיר «Page not found», ואף עמוד ב‑Get-Site-Pages אינו נוגע בטבלה; System-Tables מטפל בטבלאות ערך בלבד. ללקוח קצה בלי MCP או REST אין מסלול עצמאי.

קיים אצל הלקוח גריד Config (התקנות ותיקות או פורטלי ניהול מותאמים):

  1. Tables ← Config — גריד ההגדרות הגולמי, עם סרגל Refresh / Settings / + Add row / Delete rows.
  2. קיימת שורה עם ה‑Name המתאים: ✎ בעמודת Action, ועדכנו את Value ל‑{ "<שם הדגל>": true }.
  3. אין שורה כזו: + Add row, ומלאו:
    • Name = שם הדגל המדויק, למשל AcceptWebToTable
    • Value = האובייקט { "AcceptWebToTable": true }, המפתח הפנימי חוזר על ה‑Name מילה במילה
  4. שמרו, וּוודאו שנשארה שורה אחת בלבד לכל דגל.

הקוד מאתר את השורה עם query.first(), בלי מיון. השורה שנוצרה ראשונה מנצחת תמיד.

הסדר התוצאה ב‑8 קריאות רצופות
ישנה false, חדשה true 8 מתוך 8 נחסמו
ישנה true, חדשה false 8 מתוך 8 עברו

שורה ישנה עם false, למשל אחת מההקמה הראשונית, תשתק שורה חדשה עם true תמיד ולא “לפעמים”. וכיבוי דגל בשורה חדשה לא ייכנס לתוקף.

ה‑Value הוא גם מקום ההגדרות של נקודת הקצה, לא רק מתג.

המפתח חל על מה הוא עושה
<שם הדגל> כולן המתג עצמו — true / false
ValidatePhoneOrEmail כולן כשהוא דלוק, השרת מחזיר 400 {"error":"missing \"PhoneNumber\" or \"Email\""} אם גם הטלפון וגם האימייל אינם תקינים. טלפון: מסירים תווים שאינם ספרות ואז נדרשות 7–14 ספרות (050-123-4567 עובר). אימייל: 6–80 תווים, מכיל @ וגם .. תקין אחד מהשניים — הבקשה עוברת
DefaultValues.Account web2table ערכי ברירת מחדל שהשרת ממלא ב‑Accounts שנוצרת כשהבקשה לא שלחה אותם
DefaultValues.Table web2table אותו דבר עבור השורה שנוצרת בטבלת היעד. זו הדרך היחידה שעובדת לקביעת SaleStatusId

הגבולות של ValidatePhoneOrEmail: 6 ספרות נדחות, 7 עוברות, 14 עוברות, 15 נדחות; a@b.c (5 תווים) נדחה, a@b.co (6) עובר, 80 תווים עוברים, 81 נדחים, aaaa@bbbb בלי נקודה נדחה. בלי הדגל, phone: "abc" עובר ב‑200 ויוצר איש קשר.

שורת Config מלאה של web2table:

JSON
{
"Name": "AcceptWebToTable",
"Value": {
"AcceptWebToTable": true,
"ValidatePhoneOrEmail": true,
"DefaultValues": {
"Account": { "LeadSourceId": "yOTdl4L99Q" },
"Table": { "SaleStatusId": "zrP1MSVBoq", "IsWeb": "true" }
}
}
}

בדיקה ויצירה ב‑REST — Master Key בלבד

Section titled “בדיקה ויצירה ב‑REST — Master Key בלבד”
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 params = new URLSearchParams({ where: JSON.stringify({ 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,
},
});
Python
# בדיקה — כמה שורות יש, ומה הערך בכל אחת
import json
import requests
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": json.dumps({"Name": "AcceptWebToTable"})},
)
PHP
<?php
// בדיקה — כמה שורות יש, ומה הערך בכל אחת
$query = http_build_query(["where" => json_encode(["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: {$APP_ID}",
"X-Parse-Master-Key: {$MASTER_KEY}",
],
]);
$response = curl_exec($ch);
curl_close($ch);
Bash
# יצירה
curl -sS -X POST "https://api.mbapps.co.il/parse/classes/Config" \
-H "X-Parse-Application-Id: $APP_ID" \
-H "X-Parse-Master-Key: $MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{"Name":"AcceptWebToTable","Value":{"AcceptWebToTable":true}}'
JavaScript
// יצירה
const res = await fetch("https://api.mbapps.co.il/parse/classes/Config", {
method: 'POST',
headers: {
'X-Parse-Application-Id': APP_ID,
'X-Parse-Master-Key': MASTER_KEY,
'Content-Type': 'application/json',
},
body: JSON.stringify({ Name: 'AcceptWebToTable', Value: { AcceptWebToTable: true } }),
});
Python
# יצירה
import requests
res = requests.post(
"https://api.mbapps.co.il/parse/classes/Config",
headers={
"X-Parse-Application-Id": APP_ID,
"X-Parse-Master-Key": MASTER_KEY,
"Content-Type": "application/json",
},
json={"Name": "AcceptWebToTable", "Value": {"AcceptWebToTable": True}},
)
PHP
<?php
// יצירה
$ch = curl_init();
curl_setopt_array($ch, [
CURLOPT_URL => "https://api.mbapps.co.il/parse/classes/Config",
CURLOPT_POST => true,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_HTTPHEADER => [
"X-Parse-Application-Id: {$APP_ID}",
"X-Parse-Master-Key: {$MASTER_KEY}",
"Content-Type: application/json",
],
CURLOPT_POSTFIELDS => json_encode(["Name" => "AcceptWebToTable", "Value" => ["AcceptWebToTable" => true]]),
]);
$response = curl_exec($ch);
curl_close($ch);

מה מחזירה נקודת הקצה כשהדגל כבוי

Section titled “מה מחזירה נקודת הקצה כשהדגל כבוי”
נקודת הקצה הסטטוס ההודעה
web2table 400 AcceptWebToTable is Disabled
web2case 400 AcceptWebToCaseLeads is Disabled
getlead 400 AcceptWebLeads is Disabled

בדיקת הדגל קורית לפני זיהוי הכפילויות, לפני ValidatePhoneOrEmail ולפני אימות השדות מול הסכימה, אבל לא לפני הכול. הסדר ב‑web2table עם דגל כבוי:

הגוף שנשלח (דגל כבוי) התשובה
{} או ללא phone 400 {"error":"missing \"phone\""}
phone בלי table 400 {"error":"missing \"table\" in request body"}
table שאינו קיים + phone 400 {"code":103,"message":"Class X does not exist."}
table קיים + phone, וכל השאר פסול (Pointer שגוי, phone לא תקין) 400 {"error":"AcceptWebToTable is Disabled"}
table או phone שאינם מחרוזת 400 {} — גוף ריק, בלי הודעה

קיום phone, קיום table וקיום המחלקה נבדקים לפני הדגל; כל השאר אחריו. “is Disabled” אומרת שהגוף עבר את שלוש הבדיקות הראשונות, לא שהוא תקין.

  • קיימת שורה ב‑Config עם ה‑Name המדויק של הדגל הנכון
  • ה‑Value אובייקט, והמפתח הפנימי זהה ל‑Name מילה במילה
  • המפתח הפנימי true / false בוליאני
  • שורה אחת בלבד עם ה‑Name הזה
  • מי שמשתמש בכמה נקודות קצה בדק את כל השורות
  • הקוד בצד הלקוח מסתעף על גוף התשובה ולא על הסטטוס