סביבות וגישה

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

שתי סביבות, לא אחת

	אפליקציית ה‑CRM	סביבת הפיתוח
מי נכנס לשם	משתמשי הקצה — אנשי מכירות, תמיכה, הנהלת חשבונות	מיישמים ומפתחים
מה עושים שם	עובדים: לקוחות, מכירות, פניות, דוחות	בונים: טבלאות, עמודים, טריגרים, הרשאות — ומוציאים את פרטי החיבור
הכתובת	https://<subdomain>.mbapps.co.il/apps/<module>/<page>	https://siteadmin.mbapps.co.il/
איפה ה‑Application Id	✘	✔ Databases ← המערכת ← לשונית Settings
איפה ה‑API Key	✘	✔ אותו מסך, בלוק API Keys

שתיהן מסתכלות על אותם נתונים בדיוק. ההפרדה היא בין “לעבוד עם המערכת” לבין “לבנות את המערכת”.

המסלול המדויק לפרטי החיבור

מתוך ה‑CRM: תפריט המשתמש (למעלה מימין) ← סביבת פיתוח. נפתחת לשונית חדשה ב‑siteadmin.mbapps.co.il — ושם Databases ← בחרו את המערכת ← לשונית Settings. שם, זה מעל זה: Application Id עם כפתור העתקה, ומתחתיו בלוק API Keys עם + Add Key.

sub.mybusiness.co.il/login/ הוא עמוד ההתחברות בלבד; הוא לא מוביל לסביבת הפיתוח, ושורש הדומיין מפנה (ב‑JavaScript) לאתר השיווקי www.mybusiness.co.il. הפירוט המלא: התחלה מהירה · אימות והרשאות.

חמשת הדומיינים

הדומיין	תפקידו	מי מדבר איתו
api.mbapps.co.il	ה‑API. גם /parse (REST) וגם /functions/{appId}/… (פונקציות השרת)	הקוד שלכם, שרתי ביניים, טפסים בדפי נחיתה
mcp.mbapps.co.il	שרת ה‑MCP — 67 כלים לסוכני AI	Claude, ChatGPT וכל לקוח MCP אחר
<subdomain>.mbapps.co.il	אפליקציית ה‑CRM של הלקוח — עמודי הריצה בעברית	משתמשי הקצה בדפדפן
siteadmin.mbapps.co.il	סביבת הפיתוח — Projects · Applications · Databases, וממנה Application Id ו‑API Keys	מיישמים ומפתחים
sub.mybusiness.co.il	עמוד ההתחברות בלבד (/login)	כל מי שנכנס למערכת

siteadmin.mbapps.co.il מארח גם את נכסי האתר (לוגואים, קבצי עמודים). זהו הדומיין השני, לצד api.mbapps.co.il, שממנו כלי ה‑MCP מוכן לשלוף תוכן קובץ.

REST API        https://api.mbapps.co.il/parse
Cloud Functions  https://api.mbapps.co.il/functions/{appId}/{functionName}
MCP                https://mcp.mbapps.co.il/

Cloud Functions אינן מתחת ל‑/parse

זו סיבת התקלה מספר 1 בתיעוד הזה. /parse/functions/getlead מחזיר {"code":141,"error":"function not found"} — הנתיב קיים, אבל אין בו אף פונקציה. הנתיב הנכון הוא /functions/{appId}/<function> — בלי /parse, ועם ה‑appId בנתיב (/parse/functions/{appId}/… מחזיר 404 Not Found). ראו פונקציות צד שרת. ושימו לב לשמות הפונקציות: הקיימות הן getlead, web2table ו‑web2case (אומתו 24.08.2026). השם הישן “web2lead” אינו רשום — הוא מחזיר 400 {"error":"User function not found"}.

כל לקוח הוא אפליקציית Parse נפרדת

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

מאפיין	ההשלכה
applicationId משלו	כל קריאה נושאת אותו; הוא מזהה איזו מערכת
Master Key משלו	אין מפתח “על” שפותח כמה מערכות
סט מחלקות משלו	הסכימה של לקוח א’ אינה הסכימה של לקוח ב’
תת‑דומיין משלו	<subdomain>.mbapps.co.il
חבילות רישוי משלו	מושבים ותוקף לכל מערכת בנפרד

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

ההשלכה הפרקטית לסוכני AI

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

אין סביבת staging

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

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

מה זה אומר לאינטגרציה: אין לכם “sandbox” לזרוק אליו 10,000 רשומות בדיקה. כל כתיבה היא בייצור, וכל כתיבה מפעילה טריגרים — כלומר עלולה לשלוח מיילים ו‑WhatsApp ללקוחות אמיתיים. ראו מגבלות ומכסות.

מודל הזהויות — מה פותח מה

האישור	היכן מקבלים	מה הוא פותח
Application Id	Settings של המערכת	מזהה בלבד. פותח את web2table / web2case; מול /parse לבדו — 119 Permission denied
API Key	Settings ← API Keys ← Add Key ← Save	הכול, בזהות Master (createdBy של רשומות שנכתבו איתו הוא _User:"Master"; GET /parse/schemas ו‑Config נפתחים). ניתן לביטול נקודתי
Master Key	סוד המערכת	הכול, עוקף כל הרשאה. אין ביטול נקודתי
Session Token	POST /parse/login	מה שהמשתמש עצמו מורשה
OAuth 2.1 (MCP)	זרימת התחברות של שרת ה‑MCP (mcp.mbapps.co.il/.well-known/oauth-authorization-server מפרסם את ה‑metadata)	התפקיד של המשתמש + הרשאות ה‑MCP שלו

הפירוט המלא, כולל מה נשמר איפה: אימות והרשאות.

איפה סודות לא נשמרים

לא ב‑JavaScript בדפדפן. לא ב‑repo. לא בקובץ .env שמסונכרן לענן. Master Key או API Key שדלף = דלף מלא של בסיס הנתונים, כי שניהם עוקפים כל הרשאה. השתמשו במנהל סודות.

חבילות ומושבים — למה משתמש חדש לא מצליח להתחבר

שלוש החלטות בלתי תלויות, ובלי כולן המשתמש תקוע:

1. משתמש — שורה ב‑_User.
2. חבילה (מושב) — רישיון. בלי חבילה המשתמש לא יכול להיכנס ל‑CRM: מסך ההתחברות מחזיר “תקלה בשיוך לאפליקצייה. פנה למנהל מערכת”.
3. תפקיד + הרשאות טבלה — בלי תפקיד כל שאילתה מוחזרת ב‑{"code":119,"error":"Permission denied for action find on class Accounts."} (אומת עם Session Token של משתמש חדש בלי תפקיד).

מגבלה ידועה — אכיפת המושב היא בממשק, לא ב‑API

POST /parse/login כן מנפיק Session Token למשתמש בלי חבילת רישוי, בעוד מסך ההתחברות של הממשק עוצר אותו עם “תקלה בשיוך לאפליקצייה. פנה למנהל מערכת” — שניהם אומתו על אותו משתמש. האכיפה יושבת בשכבת האפליקציה. מי שבונה זרימת אימות משלו לא יכול להסתמך על “login נכשל” כבדיקת רישוי — הסשן שיתקבל פשוט לא יראה שום טבלה. ראו דוח הבאג core-api-13.

משתמשי פורטל (isPortalUser: true) הם חריג: הם אינם צורכים מושב, ולכן פורטל לקוחות אינו מוגבל ברישוי.

טבלאות חדשות נולדות בלי הרשאות לתפקידים שלכם

כשנוצרת טבלה חדשה דרך ה‑API של הסכימה (POST /parse/schemas/<Table>) ה‑CLP שלה ריק בכל שש הפעולות. דרך Create-Table של ה‑MCP הוא לא ריק אבל גם לא שימושי: find/get דורשים רק requiresAuthentication, ו‑create/update/delete פתוחים ל‑role:Admin בלבד (אומת). בשני המקרים התוצאה בממשק למשתמש שאינו Admin היא “השדות מופיעים ריקים” ו“המשתמש לא רואה כלום”, וזו סיבת התקלה מספר 1 אחרי הקמה — הגדירו CLP לכל תפקיד מיד אחרי היצירה.

צ’קליסט לפני הקריאה הראשונה

1. יש לי Application Id — מ‑Settings של המערכת, לא מכתובת ה‑URL.
2. יש לי API Key — יצרתי אותו ולחצתי Save, ואז ריעננתי את המסך וראיתי Created Date.
3. אני יודע לאיזו מערכת אני מחובר — כי כל מערכת היא אפליקציה נפרדת.
4. הסודות שלי יושבים במנהל סודות, לא בקוד.
5. אני יודע שכל כתיבה שלי היא בייצור ומפעילה אוטומציות.

המשך מכאן

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