web2table — יצירת רשומה מקושרת

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

יוצר שורה בכל טבלת יעד (Sales, Cases, Orders, טבלה מותאמת) וגם איש קשר ב‑Accounts, אם הוא עדיין לא קיים. איש קשר קיים נמצא ומקושר, לא משוכפל.

web2sale אינה קיימת · web2case דווקא כן

“צור מכירה מהטופס” = web2table עם "table": "Sales" — אין נקודת קצה בשם web2sale (התשובה: 400 {"error":"User function not found"}).

לעומת זאת web2case כן קיימת: היא נשלטת בדגל נפרד AcceptWebToCaseLeads, אינה מקבלת table, ומחזירה {"success":true,"accountId":…,"caseId":…}. אלא אם יש סיבה ספציפית, עדיף להשתמש ב‑web2table עם "table": "Cases" — חוזה אחד לכל הטפסים.

גוף הבקשה

JSON

{
  "table": "Sales",
  "phone": "0501234567",
  "email": "israel@example.co.il",
  "account_Name": "ישראל ישראלי",
  "account_City": "תל אביב",
  "table_Name": "פנייה מדף נחיתה",
  "table_Total": 1500,
  "table_Comment": "הגיע מדף הנחיתה"
}

חובה: table (שם המחלקה המדויק) וגם phone. בלי phone התשובה היא 400 {"error":"missing \"phone\""}.

phone הוא חובה — והסטטוס הוא 400

מסמכים ישנים מתארים את הדרישה כ”אחד מתוך phone / email / idnum” — בפועל הקוד הפרוס דורש phone, ומחזיר 400 {"error":"missing \"phone\""} בלעדיו, גם כשנשלחו email ו‑idnum (אומת).

החוזה הבטוח: שלחו phone תמיד. התייחסו ל‑email ול‑idnum כמפתחות איתור נוספים — הם מרחיבים את זיהוי הכפילויות (כל אחד מהם לחוד אכן מאתר איש קשר קיים), אך אינם מחליפים את הטלפון.

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

שמות השדות בדוגמה חייבים להתאים לסכימה שלכם

בסכימת Sales של תבנית vanilla אין שדה בשם Title ואין Amount — שדה הסכום הוא Total, ושדה הכותרת הוא Name. מפתח שאינו קיים בסכימה נזרק בשקט עם 200. שלפו סכימה לפני שאתם מעתיקים דוגמה.

שלוש קבוצות שמות השדות

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

הקבוצה	קידומת	דוגמאות	מה השרת עושה
מפתחות איתור	אין	phone, phone2, email, email2, idnum, table	מזינים את זיהוי הכפילויות. באיש קשר חדש: phone→PhoneNumber, email→Email, idnum→CompanyId
שדות Accounts	account_	account_Name, account_F_name, account_City, account_CompanyId	מוחלים רק כשנוצר איש קשר חדש
שדות טבלת היעד	table_	table_Name, table_Total, table_Comment	מוחלים על השורה החדשה, אחרי אימות מול הסכימה
תוספות ברמה העליונה	אין	Name, CampaignName, PageName, isExistsAccountCheck	ראו “שדות שנקבעים אוטומטית”

הטעות הנפוצה ביותר כאן

שליחת account_PhoneNumber במקום phone. מפתחות האיתור הם בלי קידומת: הגרסה עם הקידומת לא מזינה את זיהוי הכפילויות, והתוצאה היא איש קשר משוכפל בכל פנייה. אומת: account_PhoneNumber אכן נכתב ל‑Accounts.PhoneNumber (ואף דורס את הערך שהגיע מ‑phone) — אבל לא מאתר. ואל תשלחו את שניהם: phone יחד עם account_PhoneNumber הוא כפילות מיותרת.

מגבלה ידועה — table_SaleStatusId נזרק בשקט (באג web-forms-02)

בטבלת Sales, השדה SaleStatusId לעולם אינו נכתב מגוף הבקשה — לא כמזהה חשוף בן 10 תווים, לא כאובייקט Pointer, ולא בשום וריאציית שם. התשובה 200 ואין שום אזהרה.

זה לא הכלל הכללי של “מפתח לא מוכר”: באותה בקשה בדיוק table_Source, table_Comment, table_Total ו‑table_OwnerId (Pointer גם הוא) כן נשמרים, וגם table_StatusId בטבלת Cases נשמר.

החלופה שעובדת: DefaultValues.Table.SaleStatusId בשורת ה‑Config (אומת), או טריגר data change על Sales.

מפתחות האיתור במלואם

חמישה מפתחות מזינים את זיהוי הכפילויות, וכולם בלי קידומת. שניים מהם — phone2 ו‑email2 — מפתחות משניים שקל לפספס, והם בדיוק מה שמונע כפילות אצל לקוח שיש לו שני מספרים או שתי כתובות:

המפתח	מה הוא עושה בחיפוש	מה הוא ממלא באיש קשר חדש
phone	✔ חובה. נסרק בחמישה פורמטים שמורים בלבד (הרשימה)	Accounts.PhoneNumber
phone2	מפתח משני — נסרק גם הוא	כלום — ראו למטה
email	השוואת שוויון, ב‑OR מול הטלפון	Accounts.Email
email2	מפתח משני	כלום — ראו למטה
idnum	ח.פ. / ת.ז. — השוואה מדויקת, בלי נרמול	Accounts.CompanyId

phone2 ו‑email2 מחפשים, אבל לא ממלאים

באימות, שניהם אכן איתרו איש קשר קיים — אבל בסכימת Accounts של תבנית vanilla אין שדות טלפון או אימייל משניים, ולכן הערך שלהם פשוט אינו נשמר בשום מקום. אם ללקוח יש שדות משניים מותאמים — מלאו אותם במפורש דרך account_<שם השדה>, ואל תניחו ש‑phone2 יגיע לשם.

לקוחות עם fork משנים את הכללים

אצל חלק מהלקוחות פותחה גרסה ייעודית של הפונקציה שמתאימה גם מול שדות אחרים (למשל טלפון/אימייל של בן או בת זוג), או שמשווה idnum מול שדה ID במקום CompanyId. בתמיכה בלקוח ספציפי — קראו את הקוד שנפרס אצלו, אל תניחו את החוזה הגנרי.

שדות שנקבעים אוטומטית בשורה החדשה

השדה	הערך
AccountId	Pointer לאיש הקשר שנמצא או נוצר
IsFirst	true לאיש קשר חדש; false רק כשאיש הקשר היה קיים וגם נשלח isExistsAccountCheck: true
Name	ה‑Name מהבקשה; אחרת "פניה ראשונה" (חדש) או "פניה חוזרת" (חוזר + isExistsAccountCheck)
CampaignName / PageName	הערך מהבקשה; אחרת "MainLandingPage"
PhoneNumber, Email	מועתקים מאיש הקשר
AccountNotExist	true — תמיד, ראו למטה

מגבלה ידועה — AccountNotExist הוא תמיד true (באג web-forms-05)

מסמכים ישנים מתארים את השדה כ‑true “אלא אם איש הקשר שנמצא הוא לקוח אמיתי (IsAccount == true)”. בפועל השדה נכתב true תמיד — גם כשאותרה רשומת Accounts עם IsAccount: true (אומת: true ב‑100% מ‑100 השורות שנבדקו).

לשדה אין ערך אבחוני. ההבחנה “פנייה ראשונה מול חוזרת” נעשית ב‑IsFirst בלבד — הוא אכן מבחין נכון, ובלבד שנשלח isExistsAccountCheck.

IsFirst תלוי בדגל שקל לשכוח

בלי isExistsAccountCheck: true בבקשה, כל שורה מסומנת IsFirst: true — גם עבור לקוח חוזר. אם הדיווח שלכם נשען על השדה הזה, שלחו את הדגל.

זיהוי כפילויות

אותה שאילתה רב‑פורמטית של getlead — כל וריאציות הטלפון, ב‑OR עם האימייל — ובנוסף CompanyId (מ‑idnum) והמפתחות המשניים phone2 / email2. הפירוט המלא: זיהוי כפילויות — מה קורה בשרת.

איש קשר קיים לא מתעדכן

שדות account_* מוחלים רק על איש קשר חדש. אם העסק רוצה “לעדכן פרטים של לקוח חוזר”, זה דורש REST API או פונקציית שרת ייעודית — לא את נקודת הקצה הזו.

תשובות

סטטוס	הגוף
200	{ "success": true, "accountId": "<objectId>", "Id": "<objectId של שורת היעד>" }
400	missing "phone" · missing "table" in request body · missing "PhoneNumber" or "Email" (ולידציה) · AcceptWebToTable is Disabled
400	{"code":103,"message":"Class X does not exist."} — שם מחלקה שאינו קיים
400	{"code":111,"message":"schema mismatch for …"} — טיפוס שגוי: Pointer באורך לא נכון, תאריך לא מרופד ("2026-6-1"), מחרוזת ב‑account_IsAccount, מספר בשדה בוליאני, מחרוזת URL בשדה File. שורת היעד לא נוצרת; מה קורה לאיש הקשר תלוי בקבוצת השדה (ראו למטה)
400	{"code":1} — אובייקט File של Parse בגוף. חוזר אחרי ~4 שניות, ובצד השרת נוצרו איש קשר ו‑5 שורות יעד כפולות (באג web-forms-10)
400	{} (גוף ריק) — table או phone שאינם מחרוזת (למשל מספר)
500	תקלת שרת

400 code 111 בשדה table_* משאיר איש קשר יתום

הבקשה אינה אטומית כשהשגיאה יושבת בקבוצת table_*. הפונקציה יוצרת קודם את איש הקשר ורק אחר כך את שורת היעד, ולכן כל שגיאת code 111 בשדה table_* (תאריך לא מרופד, Pointer שנדחה, בוליאני שנשלח כמספר, שדה File) מחזירה 400 ומשאירה ב‑Accounts איש קשר חדש בלי שום רשומה עסקית מקושרת (אומת ב‑forms-b-01, שלושה שחזורים). שדה File הוא רק מקרה אחד מתוך הקבוצה, לא החריג היחיד.

שגיאת code 111 בשדה account_* (למשל account_IsAccount: "true") כן אטומית: לא נוצר איש קשר ולא שורת יעד.

מה עושים: אחרי 400 אל תניחו שכלום לא קרה. או שמנקים את איש הקשר שנוצר, או ששולחים שוב עם אותו phone, והבדיקה תזהה את איש הקשר הקיים ותקשר אליו את השורה במקום ליצור עוד אחד.

כל שגיאה עסקית חוזרת כ‑400 — הסתעפו על הגוף, לא על הסטטוס

מקורות ישנים מדברים על 403 לדגל כבוי ועל 422 לשדה חסר. בפועל נמדד 400 בכל המקרים — ההודעות עצמן נכונות מילה במילה, רק הסטטוס שונה. קוד לקוח שכתוב if (res.status === 403) פשוט לא ייכנס לענף הזה לעולם.

אין returnOrigin בגוף התשובה המוצלחת — המפתחות הם success, accountId ו‑Id בלבד.

שני מקרי שימוש

הרשמה לקורס

JavaScript

const APP_ID = 'הדביקו-כאן';

const COURSE_MAP = {
  'קורס יסודות CRM':  'aB3dEf9HiJ',
  'סדנת אוטומציות':   'kLm4NoP7Qr',
};

async function submitRegistration(f) {
  const data = {
    table: 'CourseRegistrations',      // שם המחלקה המדויק
    phone: f.phone,                    // חובה, בלי קידומת
    email: f.email,
    idnum: f.idNumber,                 // → Accounts.CompanyId על איש קשר חדש

    account_F_name: f.firstName,
    account_L_name: f.lastName,
    account_City:   f.city,

    table_CourseId:     COURSE_MAP[f.course],   // objectId חשוף
    table_StartDate:    f.startDate,            // ISO שטוח: "2026-09-01"
    table_Comment:      f.notes,
    PageName:           'course-landing-2026',
    isExistsAccountCheck: true,                 // כדי ש-IsFirst יהיה אמין
  };

  Object.keys(data).forEach((k) => { if (data[k] == null || data[k] === '') delete data[k]; });

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

  const body = await res.json().catch(() => ({}));
  if (!res.ok) {
    // כל שגיאה עסקית חוזרת כ-400 — ההבחנה היא לפי הגוף
    const e = body.error || body.message || '';
    if (/Disabled/.test(e))  throw new Error('AcceptWebToTable כבוי במערכת');
    if (/missing/.test(e))   throw new Error('חסר טלפון או שם טבלה');
    throw new Error('שגיאת שרת: ' + e);
  }
  return body;   // { success, accountId, Id }
}

לקוח (ולא ליד) + בחירה מרובה

JavaScript

const data = {
  table: 'Orders',
  phone: '0501234567',
  account_Name:      'חברת דוגמה בע"מ',
  account_IsAccount: true,          // בוליאני אמיתי! → נוצר כלקוח, לא כליד
  account_CompanyId: '514999999',
  table_Total:  '2400',
  table_array_tags_Pointer_Tags: ['GGZUYqBjqT', 'io3Z6YsMcG'],
};

מגבלה ידועה — account_IsAccount מקבל רק בוליאני; מחרוזת מפילה את הבקשה (באג web-forms-04)

זהו החריג היחיד שנמצא לכלל “מחרוזת "true" / "false" מתקבלת בשדה בוליאני”. באימות החוזר (08.2026):

מה נשלח	מה קרה
account_IsAccount: "true" (וגם "false")	400 {"code":111,"message":"schema mismatch for Accounts.IsAccount; expected Boolean but got String"} — הבקשה כולה נכשלת, לא נוצר איש קשר ולא שורת יעד
account_IsAccount: true	200 — IsAccount: true, נוצר לקוח
account_IsAccount: false	200 — נוצר ליד
account_dontSendEmail: "true" (שדה בוליאני רגיל)	200 — המחרוזת מומרת ל‑true
account_dontSendEmail: 1	400 code 111 — מספר נדחה בכל שדה בוליאני

מסמכים ישנים מדגימים כאן את המחרוזת. אל תעתיקו אותם — שלחו בוליאני אמיתי, וכאשר הטופס מגיע כ‑form-urlencoded (הכול מחרוזות) — המירו בצד שלכם לפני השליחה.

שדות בחירה מרובה (array_*_Pointer_*) מקבלים מערך של objectId חשופים, עם הקידומת המתאימה לקבוצה.

הפעלה — דגל נפרד משל עצמו

שדה	ערך
Name	AcceptWebToTable
Value	{ "AcceptWebToTable": true }

הדגל של getlead לא מפעיל את web2table

אומת: בטננט שבו AcceptWebLeads דלוק, web2table החזירה 400 "AcceptWebToTable is Disabled" עד שהוקמה שורה נפרדת משלה. זו הסיבה הנפוצה ביותר לשגיאה אחרי שהטופס הראשון של הלקוח כבר עבד. בדקו את שתי השורות בטבלת Config. המסלול המלא, וכללי השורה היחידה: הפעלת קליטה מהאתר.

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

המפתח	מה הוא עושה
AcceptWebToTable	המתג עצמו
ValidatePhoneOrEmail	אכיפה בצד השרת: 400 missing "PhoneNumber" or "Email" כשגם הטלפון (מסירים תווים שאינם ספרות, ואז 7–14 ספרות) וגם האימייל (6–80 תווים, מכיל @ ו‑.) אינם תקינים
DefaultValues.Account	ערכי ברירת מחדל לאיש הקשר שנוצר
DefaultValues.Table	ערכי ברירת מחדל לשורה שנוצרת בטבלת היעד — למשל סטטוס פתיחה או דגל “הגיע מהאתר”, בלי לחשוף מזהים בקוד הדף

JSON

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

שני כללים על DefaultValues — שניהם אומתו בפועל:

• הן מוחלות רק על שדות שהבקשה לא שלחה. ערך שנשלח בגוף הבקשה מנצח (נבדק על account_City ועל table_Source).
• הן כפופות לאותם טיפוסים של שכבת הטפסים: Pointer כמזהה חשוף בן 10 תווים, תאריך ISO שטוח. ראו מיפוי שדות.

DefaultValues.Table הוא הדרך היחידה לקבוע SaleStatusId

table_SaleStatusId בגוף הבקשה אינו נכתב (באג web-forms-02) — אבל אותו ערך בדיוק דרך DefaultValues.Table כן נשמר. אומת באותה סדרת בדיקות.

מתי DefaultValues.Table עדיף על שליחה מהדף

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

מודל האבטחה — שלוש עובדות שקובעות ארכיטקטורה

אומתו בפועל על מערכת חיה (08.2026):

1. כתיבה אנונימית ישירה ל‑REST חסומה ב‑CAPTCHA — פתיחת CLP לא עוזרת. POST /parse/classes/<Table> עם Application Id בלבד נדחה עם code 119, גם אחרי הגדרת create: {"*": true} בפועל. שער ה‑CAPTCHA יושב לפני בדיקת ההרשאות.
2. web2table רץ בהרשאות מוגברות ועוקף CLP. באימות ה‑CLP של Sales נסגר לחלוטין ({} לכל פעולה) — והפונקציה עדיין יצרה שורה והחזירה 200. המסקנה המעשית: השאירו את ההרשאות של טבלת היעד סגורות. פתיחתן היא חשיפה נטו בלי שום תועלת.
3. web2table הוא create‑only. אין לו סמנטיקת עדכון: שליחת objectId או table_objectId לא פונה לשורה קיימת — מזהה חדש חוזר בתשובה וכל קריאה מוסיפה שורה.

מה עושים כשצריך בכל זאת “עדכון מקישור ציבורי”

התבנית: טבלת קליטה + טריגר השלכה. הדף הציבורי יוצר שורה בטבלת ביניים ייעודית, וטריגר data‑change על אותה טבלה משליך את הערכים על אובייקט העסק האמיתי (update-object עם connection: "source.<שדה Pointer>"). כך טבלת העסק נשארת סגורה לכתיבה אנונימית.

שלוש השלכות שכדאי לתעד מראש כדי שמישהו לא “יתקן” אותן שנה אחר כך:

• הקישור חייב לשאת phone (שדה חובה), כלומר מספר טלפון של לקוח נוסע ב‑URL ונוחת בלוגים של שרתים. זו החלטת פרטיות שצריך להעלות מול הלקוח, לא להסתיר — החלופה היא טוקן אטום לכל רשומה שנפתר בצד שרת.
• אינטראקציה דו‑שלבית (דירוג עכשיו, הערה כעבור רגע) מייצרת שתי שורות קליטה לתגובה אחת. זו התנהגות נכונה: טבלת הקליטה היא היומן הגולמי, ואובייקט העסק מחזיק את התשובה הסופית.
• טריגר שמגיב לקריאה הראשונה ירוץ לפני שהנתונים של השנייה קיימים. אל תרכיבו גוף הודעה או משימה משדה שמגיע בקריאה המאוחרת — הפנו את הקורא לרשומה.

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

רשימת בדיקה

• table הוא שם המחלקה המדויק (לא התווית בעברית — היא מחזירה code 100, לא missing "table")
• phone נשלח, בלי קידומת
• נשלפו סכימות Accounts וגם טבלת היעד, וכל שדה אומת
• Pointer כמחרוזת של 10 תווים בדיוק (אורך אחר → 400 code 111; אם השגיאה ב‑table_* נשאר איש קשר יתום)
• תאריכים כ‑ISO מרופד (2026-06-01); לא מרופד → 400 code 111, ו‑dd/mm/yyyy נקרא כחודש/יום
• אין שדה File בגוף — 400 ובכל זאת נוצרות רשומות (עד 5 כפולות)
• account_IsAccount — אם נדרש, נשלח כבוליאני ולא כמחרוזת (מחרוזת → 400 לכל הבקשה)
• SaleStatusId נקבע דרך DefaultValues.Table ולא דרך table_SaleStatusId
• isExistsAccountCheck: true אם IsFirst משמעותי לדיווח — ו‑AccountNotExist לא משמש לשום הבחנה
• AcceptWebToTable דלוק — שורה אחת בלבד
• טיפול השגיאות בקוד מסתעף על גוף התשובה ולא על 403/422
• ה‑CLP של טבלת היעד נשאר סגור
• הבנתם ותיעדתם שכל קריאה מוסיפה שורה

המשך

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