דלגו לתוכן
MyBusiness CRMMyBusiness CRMMyBusiness למפתחיםלמפתחים

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

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

טפסים מהאתר — מאיזו נקודת קצה מתחילים

עודכן 29.08.2026

יש נקודות קצה שנועדו להיקרא מדף חיצוני — מדף נחיתה, מטופס יצירת קשר, מטופס הרשמה. הן רצות בצד השרת, לא דורשות Master Key ולא SDK, ונועדו לרוץ מהדפדפן של גולש אנונימי.

העמוד הזה עונה על שאלה אחת: באיזו מהן להשתמש — ומה משותף להן לפני שיורדים לפרטים.

טבלת ההחלטה

Section titled “טבלת ההחלטה”
getlead web2table
מה נוצר שורה אחת ב‑Accounts עם IsAccount: false — כלומר ליד שורה בטבלת היעד (Sales, Cases, Orders, טבלה מותאמת) וגם איש קשר ב‑Accounts, אם הוא עוד לא קיים
מתי הטופס לוכד איש קשר בלבד — שם, טלפון, אימייל, מקור הטופס צריך ליצור גם רשומה עסקית מקושרת: מכירה, פנייה, הרשמה לקורס, הזמנה
שדה חובה לפחות אחד מ‑PhoneNumber / Email table וגם phone
שמות שדות שטוחים, בדיוק כמו בסכימת Accounts שלוש קבוצות עם קידומות: ללא קידומת / account_ / table_
דגל ההפעלה AcceptWebLeads AcceptWebToTable
איש קשר קיים לא ממוזג — נוצרת שורת ליד חדשה שמסומנת ככפולה נמצא ומקושר, ולא מתעדכן
התיעוד getlead web2table

כלל אצבע: אם אחרי השליחה איש המכירות צריך לפתוח רשומה (מכירה/פנייה/הרשמה) ולא רק כרטיס איש קשר — זה web2table.

חוזה הכותרות — משותף לשתיהן

Section titled “חוזה הכותרות — משותף לשתיהן”
POST https://api.mbapps.co.il/functions/{appId}/getlead
POST https://api.mbapps.co.il/functions/{appId}/web2table
Bash
curl -X POST "https://api.mbapps.co.il/functions/{appId}/getlead" \
  -H "Content-Type: application/json" \
  -H "X-Parse-Application-Id: {appId}" \
  -d '{ "Name": "ישראל ישראלי", "PhoneNumber": "0501234567" }'
JavaScript
const res = await fetch(`https://api.mbapps.co.il/functions/${appId}/getlead`, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-Parse-Application-Id': appId,
  },
  body: JSON.stringify({
    Name: 'ישראל ישראלי',
    PhoneNumber: '0501234567',
  }),
});
Python
import requests


res = requests.post(
    f"https://api.mbapps.co.il/functions/{appId}/getlead",
    headers={
        "Content-Type": "application/json",
        "X-Parse-Application-Id": appId,
    },
    json={
        "Name": "ישראל ישראלי",
        "PhoneNumber": "0501234567",
    },
)
PHP
<?php
$ch = curl_init();
curl_setopt_array($ch, [
    CURLOPT_URL => "https://api.mbapps.co.il/functions/{$appId}/getlead",
    CURLOPT_POST => true,
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER => [
        "Content-Type: application/json",
        "X-Parse-Application-Id: {$appId}",
    ],
    CURLOPT_POSTFIELDS => json_encode([
        "Name" => "ישראל ישראלי",
        "PhoneNumber" => "0501234567",
    ], JSON_UNESCAPED_UNICODE),
]);
$response = curl_exec($ch);
curl_close($ch);
מה הערך
שיטה השתמשו ב‑POST. (בבילד שנבדק גם GET עם query string מתקבל ויוצר רשומה; ראו האזהרה למטה)
כתובת בסיס https://api.mbapps.co.il/functions/{appId}/ — לא מתחת ל‑/parse
Content-Type application/json. (application/x-www-form-urlencoded מתקבל גם הוא בפועל, אבל אין סיבה להשתמש בו)
X-Parse-Application-Id ה‑Application Id של המערכת. שלחו אותה תמיד — אך שימו לב שבבילד שנבדק היא אינה נאכפת: המזהה שקובע הוא זה שבנתיב
גוף JSON שטוח. אין multipart
קבצים לא נתמכים — ואסור לשלוח. שדה File מחזיר 400, אבל הרשומות כן נוצרות בצד השרת: איש הקשר תמיד, ועם אובייקט File גם 5 שורות יעד כפולות (באג web-forms-10)

ה‑Application Id הוא מזהה ציבורי, לא סוד

Section titled “ה‑Application Id הוא מזהה ציבורי, לא סוד”

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

כן — וזה מתוכנן. ה‑Application Id הוא מזהה האפליקציה מול השרת, לא אישור גישה. הוא אינו Master Key ואינו API Key: הוא לא מאפשר לקרוא נתונים, לא לעדכן ולא למחוק. מי שמחזיק אותו יכול לעשות רק דבר אחד — לקרוא לנקודות הקצה הפומביות האלה, בדיוק כמו למלא את הטופס באתר שלכם.

השערים האמיתיים הם שלושה, וכולם בצד השרת:

  1. דגל ה‑Config שמפעיל את נקודת הקצה בכלל — ראו דגלי Config.
  2. ולידציה של השדות מול הסכימה, ובחירה של הלקוח להפעיל ValidatePhoneOrEmail.
  3. שער ה‑CAPTCHA של Parse שחוסם כל כתיבה אנונימית אחרת — ראו מודל האבטחה.

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

Section titled “אזהרה מראש: שתי הנקודות מדברות שני דיאלקטים”

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

JSON
// getlead — שטוח, בשמות הסכימה
{ "Name": "ישראל ישראלי", "PhoneNumber": "0501234567", "City": "תל אביב" }


// web2table — אותו איש קשר, שמות אחרים לגמרי
{ "table": "Sales", "phone": "0501234567",
  "account_Name": "ישראל ישראלי", "account_City": "תל אביב" }
getlead web2table
טלפון PhoneNumber phone (בלי קידומת)
אימייל Email email (בלי קידומת)
ח.פ. / ת.ז. CompanyId idnum (בלי קידומת)
שם Name account_Name
עיר City account_City

הסדר המומלץ לעבודה

Section titled “הסדר המומלץ לעבודה”

חמישה צעדים, בסדר הזה. דילוג על צעד 1 או 2 הוא הסיבה לרוב התקלות:

  1. הדליקו את הדגל. נקודת הקצה חסומה עד שמפעילים אותה בטבלת Config — ראו דגלי Config. 400 {"error":"…​ is Disabled"} בקריאה הראשונה זה כמעט תמיד זה.
  2. שלפו את הסכימה של Accounts (ושל טבלת היעד ב‑web2table), ובנו מפת שדות — ראו מיפוי שדות.
  3. כתבו את הטופס לפי הדיאלקט של נקודת הקצה: getlead או web2table.
  4. הבינו מה יקרה לכפילויות לפני שהלקוח שואל — ראו זיהוי כפילויות.
  5. הטמיעו וסגרו קצוות: WordPress / Wix / HTML, ואחר כך מודל האבטחה לפני שמישהו “מתקן” הרשאות.

כל עמודי הפרק

Section titled “כל עמודי הפרק”
העמוד מה תמצאו בו
getlead נקודת הקצה, שדות מוגנים, טיפוסים, קוד מלא לטופס נחיתה, צ’קליסט
web2table שלוש קבוצות השמות, שדות אוטומטיים, IsFirst, שני מקרי שימוש
דגלי Config שלוש שורות הדגל, המסלול בממשק, ולמה שורה כפולה שוברת הכול
מיפוי שדות שליפת סכימה, מפות Pointer, טבלת הטיפוסים של שכבת הטפסים
זיהוי כפילויות מה בדיוק רץ בשרת, נרמול טלפון, סטטוסים, IsFirst
מודל האבטחה למה CLP פתוח לא עוזר, create‑only, תבנית טבלת קליטה
אבחון תקלות תסמין ← סיבה ← בדיקה, בסדר הנכון
הטמעה בפועל WordPress, Wix, HTML, שרת ביניים, ומה קורה אחרי ההצלחה

המשך

Section titled “המשך”