getlead — לכידת ליד מהאתר

POST https://api.mbapps.co.il/functions/{appId}/getlead

שימו לב לשם — getlead, לא “web2lead”

בחומרים ישנים (וכן בסקיל myb-p-web2lead-web2table של הפלאגין) הפונקציה הזו נקראת web2lead — אבל השם הרשום בשרת הוא getlead. קריאה ל‑/functions/{appId}/web2lead מחזירה 400 {"error":"User function not found"}. כל מה שכתוב בעמוד הזה אומת בפועל מול טננט חי (24.08.2026) על השם getlead: יצירת ליד, זיהוי כפילויות, דגל ההפעלה, עקיפת סטטוס ושדות מוגנים. שם הפונקציה אינו תלוי רישיות — getLead ו‑GetLead עובדים גם הם — אבל כתבו getlead.

יוצר שורה חדשה בטבלה Accounts עם IsAccount: false, כלומר ליד.

זו נקודת הקצה הנכונה כשהטופס לוכד איש קשר בלבד. אם הטופס צריך גם ליצור רשומה מקושרת (מכירה, פנייה, הרשמה לקורס), עברו ל‑web2table. לא בטוחים? טבלת ההחלטה.

למה זה בטוח מהדפדפן

אין כאן Master Key, אין סשן ואין SDK. הכותרת היחידה היא ה‑Application Id, שהוא מזהה ציבורי. השער האמיתי הוא דגל ההפעלה בצד השרת + בדיקת התקינות (validation) שהפונקציה מבצעת, לא סודיות המזהה. בטוח מבחינת סודות, אבל לא סגור: כל מי שיש לו את ה‑appId יכול לקרוא לנקודה, גם ב‑GET. ראו את הסעיף על CAPTCHA ואנטי‑ספאם למטה.

הכותרות והגוף

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", "Email": "israel@example.co.il", "City": "תל אביב" }'

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',
    Email: 'israel@example.co.il',
    City: 'תל אביב',
  }),
});

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",
        "Email": "israel@example.co.il",
        "City": "תל אביב",
    },
)

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",
        "Email" => "israel@example.co.il",
        "City" => "תל אביב",
    ], JSON_UNESCAPED_UNICODE),
]);
$response = curl_exec($ch);
curl_close($ch);

חובה: לפחות אחד מ‑PhoneNumber או Email.

מה נאכף תמיד ומה תלוי בדגל — נמדד בפועל

היעדר מוחלט של שניהם נדחה תמיד: בקשה בלי PhoneNumber ובלי Email מחזירה 400 {"error":"missing \"PhoneNumber\" or \"Email\""} גם כששורת ה‑Config מכילה רק את מתג ההפעלה (אומת 24.08.2026).

בדיקת התקינות (פורמט הטלפון/האימייל) פעילה רק כשהמפתח ValidatePhoneOrEmail דלוק בתוך אובייקט ה‑Value של שורת ה‑Config — ראו מה עוד יושב בתוך Value. בלי הדגל, PhoneNumber: "123" עובר ויוצר ליד (נמדד); עם הדגל — נדחה באותה שגיאת missing. הדליקו אותו — הוא הגנת הבסיס מפני זבל.

הסטטוס שחוזר הוא 400 ולא 422 — כל התיעוד ההיסטורי של השכבה הזו מדבר על 422; הקוד הפרוס מחזיר 400.

שמות שדות: ללא קידומת — בדיוק כמו בסכימה של Accounts (Name, F_name, L_name, PhoneNumber, Email, Address, City, CompanyId, וכל שדה מותאם). ראו מיפוי שדות מטופס לסכימה.

הפונקציה שומרת רק שדות שקיימים בסכימה

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

תשובות

סטטוס	הגוף	המשמעות
200	{ "result": { "success": true, "leadId": "<objectId>" } }	הליד נוצר
400	{"error":"missing \"PhoneNumber\" or \"Email\""}	חסרים PhoneNumber וגם Email, או ששניהם לא תקינים (כש‑ValidatePhoneOrEmail דלוק)
400	{"error":"AcceptWebLeads is Disabled"}	דגל ה‑Config כבוי — ראו דגלי Config
400	{"error":"User function not found"}	שם פונקציה שגוי — למשל השם הישן web2lead. הפונקציה נקראת getlead
500	—	תקלת שרת

תשובת ההצלחה עטופה ב‑result

בניגוד ל‑web2table, שמחזירה {"success":true,…} ישירות, getlead מחזירה את גוף ההצלחה עטוף: {"result":{"success":true,"leadId":"…"}} (נמדד בפועל). קראו את המזהה מ‑body.result.leadId. שגיאות (400) חוזרות לא עטופות — {"error":"…"} — בשתי הפונקציות.

למה 400 ולא 403 / 422

שכבת הטפסים מחזירה 400 בכל שגיאה עסקית, וההבחנה נעשית לפי מחרוזת ה‑error בגוף. זה נמדד בפועל על web2table ו‑web2case: דגל כבוי → 400, phone חסר → 400, ולידציה שנכשלה → 400. אל תכתבו קוד לקוח שמסתעף על 403 או 422 — הסתעפו על הגוף.

שדות מוגנים — אל תשלחו אותם

השדה	מי קובע אותו
IsAccount	השרת — תמיד false
fromWeb2lead	השרת — תמיד true על ליד שנוצר מהפונקציה
LeadStatusId	מנגנון זיהוי הכפילויות (ניתן לעקוף עבור ליד חדש בלבד)
objectId, createdAt, updatedAt, ACL, createdBy, updatedBy	שדות מערכת

fromWeb2lead — קיים, ונוצר בקריאה הראשונה

השרת מציב fromWeb2lead: true על כל ליד שנוצר מ‑getlead (אומת 24.08.2026 בקריאת REST על הרשומה שנוצרה). שימו לב שבטננט תבנית נקי העמודה אינה קיימת בסכימת Accounts עד הקריאה המוצלחת הראשונה — היא נוצרת עצל (lazy) עם הליד הראשון מהטופס. אל תיבהלו אם GET /parse/schemas/Accounts לא מציג אותה לפני שהטופס רץ פעם אחת.

זיהוי כפילויות — מה בדיוק קורה בשרת

1. הטלפון מנורמל: מסירים תווים שאינם ספרות, ו‑972… הופך ל‑0….
2. השרת מריץ שאילתה על Accounts.PhoneNumber מול כל הווריאציות: 05XXXXXXXX, 9725XXXXXXX, +9725XXXXXXX, 05X-XXXXXXX, +972-5X-XXXXXXX (ומקבילותיהן לקווי נייח) — ב‑OR עם Accounts.Email == <האימייל>.
3. כפילות לא חוסמת יצירה. תמיד נוצרת שורה חדשה:
   • נמצאה התאמה → הליד החדש מקבל את סטטוס “ליד כפול” (ברירת המחדל בתבנית: QYvLV9xHE1).
   • לא נמצאה → הוא מקבל את ה‑LeadStatusId שנשלח בבקשה, ואם לא נשלח, את סטטוס “ליד חדש” (ברירת המחדל: e9TwcETDGq).

אל תקודדו את שני ה‑objectId האלה בלי לבדוק

QYvLV9xHE1 ו‑e9TwcETDGq הם ברירות מחדל של התבנית. במערכות מותאמות הם שונים. אמתו מול LeadStatuses של הלקוח לפני שאתם מסתמכים עליהם.

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

טיפוסים — הפורמט של שכבת הטפסים

הטבלה הזו נמדדה בפועל על web2table, שמשתמשת באותה שכבת המרה:

טיפוס בסכימה	מה שולחים	הערות מהאימות
String	מחרוזת	מחרוזת ריקה לא נשמרת — השדה כלל אינו נכתב
Number	מספר או מחרוזת מספרית	"1,500" ו‑"abc" נשמרים כ‑null, לא נזרקים
Boolean	true / false (בוליאני) — מומלץ. המחרוזת "true" / "false" מתקבלת ברוב השדות	חריג: ב‑IsAccount מחרוזת מפילה את כל הבקשה ב‑400 (code 111, “expected Boolean but got String”) — רק בוליאני אמיתי עובד (באג web-forms-04). מספר (1 / 0) נדחה ב‑400 בכל שדה בוליאני
Date	מחרוזת ISO שטוחה מרופדת: "2026-06-10"	גם ISO מלא וגם {"__type":"Date","iso":…} עובדים. "2026-6-1" (לא מרופד) מפיל את כל הבקשה ב‑400 (code 111). זהירות: "10/06/2026" מתקבל — אבל נקרא כ‑6 באוקטובר (חודש/יום אמריקאי). שלחו ISO בלבד
Pointer	מחרוזת objectId חשופה, 10 תווים: "vOZLqOWnQf"	גם {"__type":"Pointer",…} עובד. אורך אחר מפיל את כל הבקשה ב‑400 (code 111). מחרוזת ריקה — 200 והשדה לא נכתב
בחירה מרובה	מערך של objectId חשופים	מערך אובייקטי Pointer נשמר כפי שנשלח — כלומר פוגם בנתונים בשקט
File	לא נתמך — אל תשלחו	מחרוזת URL → 400 (code 111) אבל איש הקשר כבר נוצר. אובייקט File → 400 (code 1) אחרי ~4 שניות, ובצד השרת נוצרו איש קשר ו‑5 שורות יעד כפולות (באג web-forms-10). קבצים מעלים בנפרד, מהשרת, אחרי שהרשומה נוצרה

מיפוי שדה Pointer מטופס

<select> בטופס שולח טקסט; ה‑API רוצה objectId. לכן שולפים פעם אחת את טבלת ה‑lookup ומטמיעים מפה סטטית בקוד:

JavaScript

// נשלף פעם אחת מטבלת LeadSource — עדכנו כשמוסיפים מקור חדש
const SOURCE_MAP = {
  'פייסבוק':     'vOZLqOWnQf',
  'גוגל':        'fHG8Rgy8Hr',
  'אתר אינטרנט': 'yOTdl4L99Q',
};

אם הערך שנבחר לא נמצא במפה, השמיטו את השדה מהגוף. אל תשלחו undefined ואל תשלחו מחרוזת ריקה.

קוד מוכן — טופס בדף נחיתה

HTML

<form id="lead-form" novalidate>
  <input name="fullName" placeholder="שם מלא" />
  <input name="phone" type="tel" placeholder="טלפון" required />
  <input name="email" type="email" placeholder="אימייל" />
  <input name="city" placeholder="עיר" />
  <select name="source">
    <option value="">איך הגעתם אלינו?</option>
    <option>פייסבוק</option>
    <option>גוגל</option>
    <option>אתר אינטרנט</option>
  </select>

  <!-- מלכודת דבש: בוט ימלא אותה, אדם לא יראה אותה כלל -->
  <input name="company_website" tabindex="-1" autocomplete="off"
         style="position:absolute;left:-9999px" aria-hidden="true" />

  <button type="submit">שליחה</button>
  <p class="form-msg" role="status" aria-live="polite"></p>
</form>

<script>
const APP_ID = 'הדביקו-כאן-את-ה-Application-Id';

const SOURCE_MAP = {
  'פייסבוק':     'vOZLqOWnQf',
  'גוגל':        'fHG8Rgy8Hr',
  'אתר אינטרנט': 'yOTdl4L99Q',
};

const form = document.getElementById('lead-form');
const msg  = form.querySelector('.form-msg');

form.addEventListener('submit', async (e) => {
  e.preventDefault();
  const f = Object.fromEntries(new FormData(form));

  // מלכודת דבש מלאה → זה בוט. מציגים "הצלחה" ולא שולחים כלום.
  if (f.company_website) { msg.textContent = 'תודה! נחזור אליכם בהקדם.'; return; }

  const data = {
    Name:        f.fullName,
    PhoneNumber: f.phone,
    Email:       f.email,
    City:        f.city,
    LeadSourceId: SOURCE_MAP[f.source],   // objectId חשוף, או undefined
  };

  // ניקוי ערכים ריקים — כדי לא לשלוח מחרוזות ריקות למערכת
  Object.keys(data).forEach((k) => { if (!data[k]) delete data[k]; });

  if (!data.PhoneNumber && !data.Email) {
    msg.textContent = 'נא למלא טלפון או אימייל';
    return;
  }

  const btn = form.querySelector('button');
  btn.disabled = true;

  try {
    const res = await fetch(`https://api.mbapps.co.il/functions/${APP_ID}/getlead`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json', 'X-Parse-Application-Id': APP_ID },
      body: JSON.stringify(data),
    });

    if (res.ok) {
      const body = await res.json();          // { result: { success: true, leadId: "..." } }
      window.dataLayer?.push({ event: 'form_submit', lead_id: body.result?.leadId });
      window.location.href = '/thank-you/';
      return;
    }
    // כל שגיאה עסקית חוזרת כ-400 — ההבחנה היא לפי הגוף, לא לפי הסטטוס
    const err = await res.json().catch(() => ({}));
    if (/Disabled/.test(err.error || ''))            msg.textContent = 'קבלת פניות מהאתר אינה מופעלת כרגע';
    else if (/missing/.test(err.error || ''))        msg.textContent = 'נא למלא טלפון או אימייל תקינים';
    else                                             msg.textContent = 'אירעה שגיאה, נסו שוב';
  } catch {
    msg.textContent = 'אין חיבור לרשת, נסו שוב';
  } finally {
    btn.disabled = false;
  }
});
</script>

הפעלה חד‑פעמית לכל מערכת

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

שדה	ערך
Name	AcceptWebLeads (String)
Value	{ "AcceptWebLeads": true } (Object — שם הדגל חוזר בתוך האובייקט)

הפונקציה קוראת את המפתח הפנימי. ערך בוליאני חשוף ("Value": true) לא ניתן אפילו לשמירה — Config.Value מוגדר Object בסכימה, ו‑REST מחזיר 400 code 111 כבר בכתיבה. שימו לב: המפתח הפנימי נבדק לפי truthiness — גם המחרוזת "false" נקראת כדלוק (מגבלה forms-a-01); כיבוי אמין הוא false בוליאני.

בממשק ה‑CRM אין עמוד Config (אומת — web-forms-07); העריכה נעשית דרך סביבת הפיתוח (סביבת פיתוח ← Databases ← המערכת ← Tables ← Config) או דרך REST.

דרך REST (דורש Master Key — הטבלה חסומה לשאר השכבות):

Bash

curl -X POST "https://api.mbapps.co.il/parse/classes/Config" \
  -H "X-Parse-Application-Id: {appId}" \
  -H "X-Parse-Master-Key: {masterKey}" \
  -H "Content-Type: application/json" \
  -d '{ "Name": "AcceptWebLeads", "Value": { "AcceptWebLeads": true } }'

JavaScript

const res = await fetch("https://api.mbapps.co.il/parse/classes/Config", {
  method: 'POST',
  headers: {
    'X-Parse-Application-Id': appId,
    'X-Parse-Master-Key': masterKey,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    Name: 'AcceptWebLeads',
    Value: { AcceptWebLeads: true },
  }),
});

Python

import requests

res = requests.post(
    "https://api.mbapps.co.il/parse/classes/Config",
    headers={
        "X-Parse-Application-Id": appId,
        "X-Parse-Master-Key": masterKey,
        "Content-Type": "application/json",
    },
    json={
        "Name": "AcceptWebLeads",
        "Value": {"AcceptWebLeads": 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: {$appId}",
        "X-Parse-Master-Key: {$masterKey}",
        "Content-Type: application/json",
    ],
    CURLOPT_POSTFIELDS => json_encode([
        "Name" => "AcceptWebLeads",
        "Value" => ["AcceptWebLeads" => true],
    ]),
]);
$response = curl_exec($ch);
curl_close($ch);

החזיקו שורה אחת בלבד לכל דגל. הקוד לוקח query.first() ללא מיון, ובאימות (16 קריאות בשני סדרי יצירה) התברר שהשורה שנוצרה ראשונה היא שמנצחת תמיד — כלומר שורה ישנה עם false תמיד תשתק שורה חדשה עם true. ראו דגלי Config.

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

מה עוד יושב בתוך Value

אובייקט ה‑Value הוא לא רק מתג — הוא גם ההגדרות של נקודת הקצה:

המפתח	מה הוא עושה
AcceptWebLeads	המתג עצמו
ValidatePhoneOrEmail	מה שהופך את בדיקת התקינות לפעילה. כשהוא דלוק, השרת דוחה ב‑400 בקשה שבה גם הטלפון וגם האימייל אינם תקינים. תקין אחד מהם — הבקשה עוברת. הגבולות נמדדו: טלפון — מסירים תווים שאינם ספרות ואז 7–14 ספרות; אימייל — 6–80 תווים, מכיל @ וגם .
DefaultValues.Account	ערכי ברירת מחדל שהשרת ממלא באיש הקשר שנוצר, כשהבקשה לא שלחה אותם. עובד רק ב‑web2table — ראו האזהרה למטה

JSON

{
  "Name": "AcceptWebLeads",
  "Value": {
    "AcceptWebLeads": true,
    "ValidatePhoneOrEmail": true,
    "DefaultValues": { "Account": { "LeadSourceId": "yOTdl4L99Q" } }
  }
}

DefaultValues.Account — לא עובד ב‑getlead (נמדד)

המנגנון אומת ועובד בשורת ה‑Config של web2table: DefaultValues.Account מילא City ו‑LeadSourceId באיש קשר חדש, וערך שנשלח בגוף הבקשה ניצח את ברירת המחדל. ב‑getlead הוא לא הופעל: באימות (24.08.2026) נוסף DefaultValues.Account.City לשורת AcceptWebLeads, נשלחה בקשה בלי City — והליד נוצר בלי הערך.

לכן: ב‑getlead שלחו כל ערך שאתם צריכים בגוף הבקשה — אל תסתמכו על DefaultValues.

הכללים של מיפוי שדות חלים גם על DefaultValues: Pointer כמזהה חשוף בן 10 תווים, בוליאני כמחרוזת.

CAPTCHA ואנטי‑ספאם

נקודת הקצה לא מאמתת reCAPTCHA, Turnstile או מלכודות דבש. יש שתי דרכים:

הנקודה עונה גם ל‑GET, וגם בלי כותרת Application Id תקינה

העמוד הזה מתעד POST, כי זו הצורה שכדאי להשתמש בה. אבל בפועל (אומת, web-forms-03, עדיין פתוח ללא retest) אותה קריאה עם אותם פרמטרים ב‑query string דרך GET יוצרת ליד מלא בדיוק כמו POST. גם בקשה שנשלחת בלי הכותרת X-Parse-Application-Id או עם ערך שגוי בה מצליחה, כי הכותרת אינה נאכפת (ה‑appId שבנתיב הוא מה שקובע).

המשמעות המעשית: מי שראה את ה‑appId שלכם בקוד המקור של הדף יכול להזרים לידים בלי JavaScript ובלי לעבור CORS — למשל דרך <img src="…/getlead?Name=…&PhoneNumber=…"> בכל אתר או מייל. מלכודת דבש בדפדפן לא עוצרת את זה כלל.

אם הטופס חשוף לספאם — שרת ביניים עם CAPTCHA הוא הפתרון היחיד שבאמת מסנן, כי רק הוא מחזיק את ה‑appId ואת ה‑secret מחוץ לדפדפן.

• מלכודת דבש: כמו בקוד למעלה. חינם, ללא חיכוך, מסננת בוטים פשוטים.
• טוקן CAPTCHA אמיתי: מאמתים אותו בשרת שלכם ורק אז מעבירים ל‑getlead. ה‑secret של CAPTCHA לעולם לא יושב בדפדפן, ולכן שרת ביניים הוא התבנית המומלצת כשיש CAPTCHA. הפרדת האחריות המלאה: מודל האבטחה.

JavaScript

// Cloudflare Worker / Express — שרת ביניים שמאמת Turnstile ואז מעביר הלאה
export async function onRequestPost({ request, env }) {
  const body = await request.json();

  const verify = await fetch('https://challenges.cloudflare.com/turnstile/v0/siteverify', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ secret: env.TURNSTILE_SECRET, response: body.token }),
  }).then((r) => r.json());

  if (!verify.success) return new Response('captcha failed', { status: 400 });

  delete body.token;
  return fetch(`https://api.mbapps.co.il/functions/${env.APP_ID}/getlead`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json', 'X-Parse-Application-Id': env.APP_ID },
    body: JSON.stringify(body),
  });
}

רשימת בדיקה לפני עלייה לאוויר

• נשלפה סכימת Accounts וכל שדה בטופס אומת מולה
• כל שדה Pointer קיבל מיפוי מטבלת ה‑lookup (ולא נשלח כטקסט חופשי)
• Pointer נשלח כמחרוזת objectId חשופה, לא כאובייקט
• בוליאנים כבוליאני אמיתי true / false (מחרוזת עוברת ברוב השדות, אבל ב‑IsAccount מפילה את הבקשה; מספר נדחה תמיד)
• תאריכים כ‑ISO שטוח מרופד (2026-06-01, לא 2026-6-1 ולא dd/mm/yyyy)
• אין שדה File בגוף — הוא מחזיר 400 ובכל זאת יוצר רשומות
• ערכים ריקים מוסרים מהגוף
• הדגל AcceptWebLeads דלוק — שורה אחת בלבד, והיא הישנה ביותר אם יש כפילות
• הטיפול בשגיאה בממשק המשתמש מסתעף על גוף התשובה ולא על קוד הסטטוס (הכול חוזר כ‑400)
• יש מלכודת דבש או CAPTCHA דרך שרת ביניים
• אירוע המרה נשלח ל‑GTM/Analytics אחרי הצלחה בלבד

המשך

• web2table — כשצריך גם רשומה בטבלת יעד
• דגלי Config — ההפעלה, ולמה … is Disabled הוא כמעט תמיד זה
• מיפוי שדות · זיהוי כפילויות · מודל האבטחה
• הטמעה בפועל — WordPress, Wix, HTML ושרת ביניים
• אבחון תקלות בטפסים · שגיאות ופתרון תקלות
• דוגמאות קוד — PHP, Python, Node, C#