סביבות וגישה

עודכן 30.08.2026

ה‑Application Id אינו במערכת שבה אתם עובדים. הוא בסביבת הפיתוח.

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

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

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

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

הדומיין	תפקידו	מי מדבר איתו
`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/

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

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

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

אין סביבת staging

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

אין 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 שלו

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

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

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

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

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

המשך מכאן

התחלה מהירה — ארבע קריאות REST ראשונות
אימות והרשאות — ארבע השיטות ומתי כל אחת נכונה
מפת הטבלאות — מה יש בפנים
מגבלות ומכסות — כל מספר שמשפיע על תכנון