תנאי שימוש ב-API הם חוזה — לא תיעוד
עמוד השירות: עורך דין מסחר דיגיטלי ו-AI: תקנון, פרטיות ודיוור.
ממשק תכנות יישומים הוא הדרך שבה מערכת אחת ניגשת לשירות של מערכת אחרת. מרגע שפתחתם ממשק לגורמים מחוץ לארגון — שותפים, לקוחות עסקיים או קהילת מפתחים — יצרתם ערוץ גישה לנתונים ולתשתית שלכם. המסמך שמסדיר את הערוץ הזה אינו תיעוד טכני אלא חוזה.
בכריתה עצמה אין ייחוד: הצעה וקיבול לפי חוק החוזים (חלק כללי), התשל״ג-1973 יכולים להתגבש גם באישור אלקטרוני ובשימוש בפועל במפתח גישה. הייחוד הוא בתוכן — ובעובדה שברוב המקרים מדובר בנוסח אחיד שצד אחד כתב מראש.
שאלה על המקרה שלכם? כתבו בוואטסאפ · 050-431-3155
האם תנאי API הם חוזה אחיד?
״חוזה אחיד״ מוגדר בסעיף 2 לחוק החוזים האחידים, התשמ״ג-1982 כנוסח של חוזה שתנאיו, כולם או מקצתם, נקבעו מראש בידי צד אחד כדי שישמשו תנאים לחוזים רבים בינו לבין אנשים בלתי מסוימים במספרם או בזהותם. תנאי שימוש בממשק שמפורסמים באתר וחלים על כל מי שנרשם עונים להגדרה כמעט תמיד.
מכאן שסעיף 5 לחוק חל: תנאי השולל או מגביל את זכות הלקוח לפנות לערכאות — בטל; תנאי הפוטר את הספק מאחריות לנזק גוף או למעשה זדון — בטל. וכן חזקות הקיפוח שבסעיף 4, ובהן פטור מאחריות שהדין מטיל או סיוג בלתי סביר שלה (פסקה 1), זכות בלתי סבירה לבטל, להשעות או לשנות חיובים מהותיים (פסקה 2), שינוי מחיר חד־צדדי לאחר הכריתה (פסקה 4), שלילת זכות או תרופה שעומדת ללקוח לפי דין (פסקה 6), סעיף בוררות (פסקאות 8–10) והתניה על הוראות הדין בדבר מקום שיפוט (פסקה 9).
לכן ״אנו רשאים לסגור את הגישה בכל עת, מכל סיבה, ללא הודעה״ אינו סעיף חזק. ניסוח שמחזיק מים מבחין בין סיבות: הפרה של מדיניות השימוש או סיכון אבטחתי מצדיקים השעיה מיידית; שינוי מסחרי מצדיק הודעה מוקדמת בפרק זמן מוגדר.
הגדרת השימוש המותר — והאסור
זהו הסעיף שממנו נגזרות רוב המחלוקות. מה שלא נאסר במפורש קשה מאוד לאסור בדיעבד:
- היקף השימוש — לאילו מטרות מותר להשתמש בנתונים, והאם מותר להציגם למשתמשי קצה של המפתח.
- מוצר מתחרה — האם מותר לבנות באמצעות הממשק שירות שמתחרה במפעיל. אם לא, יש להגדיר מהי תחרות.
- העברה לצד שלישי — האם מותר להעביר את הגישה, למכור אותה, או לשלב אותה במוצר שנמכר הלאה.
- שאיבה והצטברות — האם מותר לאחסן את הנתונים באופן קבוע ולבנות מהם מאגר עצמאי, או רק לעשות בהם שימוש נקודתי.
- מגבלות קצב — מספר קריאות לשנייה, לדקה וליום, והתוצאה של חריגה: האטה, חיוב נוסף או חסימה. מגבלה שלא נקבעה בחוזה קשה לאכוף בדיעבד.
נקודה שנשכחת: התיעוד הטכני עצמו. ברוב ההסכמים הוא מוכנס פנימה בהפניה (״בכפוף לתיעוד המתפרסם מעת לעת״), וכך הופך לחלק מהחוזה — על כל השלכותיו. מי שמאמץ מבנה כזה צריך לשמור גרסאות מתוארכות של התיעוד, שכן בסכסוך תישאל השאלה מה בדיוק הותר במועד הרלוונטי. אותו כלל חל על ספריות עזר וערכות פיתוח: הרישיון החל עליהן, ולעתים גם רישיונות קוד פתוח שמשולבים בהן, מצטרפים לתמונה החוזית.
זמינות, גרסאות והוצאה משימוש
מפתח שבנה מוצר שלם על ממשק חיצוני חשוף לשני סיכונים: שהממשק ייפול, ושהוא ישתנה. ההסכם צריך לטפל בשניהם בנפרד. לעניין זמינות — יעד זמינות, אופן המדידה, וסעד ממשי ולא רק זיכוי סמלי. לעניין שינויים — מדיניות גרסאות ברורה, התחייבות לתקופת תמיכה מינימלית בגרסה קיימת, ולוח זמנים להודעה מוקדמת לפני הוצאת יכולת משימוש.
הוצאה פתאומית של יכולת מרכזית משימוש היא בדיוק המצב שבו חזקת הקיפוח שבסעיף 4(2) לחוק החוזים האחידים רלוונטית: זכות בלתי סבירה של הספק לשנות חיובים מהותיים לפי החוזה. מנגד, מפעיל שקבע מראש מדיניות גרסאות סבירה, פרסם לוח זמנים והודיע בהתאם — נמצא בעמדה טובה בהרבה.
פותחים ממשק למפתחים חיצוניים, או שנחסמה לכם גישה שעליה בנוי מוצר שלם? כדאי לעבור על התנאים לפני שמתקדמים.
מפתחות גישה, שימוש לרעה וחוק המחשבים
מפתח גישה הוא אמצעי הזדהות, ולעתים קרובות הוא זולג — נשמר בקוד פתוח, מועבר בין עובדים, או נגנב. ההסכם צריך לקבוע במפורש: חובת שמירה על סודיות המפתח, איסור שיתוף, חובת הודעה מיידית על חשש לדליפה, ואחריות לשימוש שנעשה באמצעותו עד למועד ההודעה.
מעבר לחוזה, חלה שכבה פלילית. חוק המחשבים, התשנ״ה-1995 קובע בסעיף 4 כי החודר שלא כדין לחומר מחשב הנמצא במחשב — דינו מאסר שלוש שנים, ובסעיף 5 כי חדירה כאמור כדי לעבור עבירה אחרת — חמש שנים. סעיף 2 אוסר על שיבוש פעולתו התקינה של מחשב או הפרעה לשימוש בו, וסעיף 6(ב) אוסר על הפצה או העברה של סיסמה או קוד גישה כדי שתבוצע אחת מהפעולות האסורות. שימוש בממשק בחריגה מהרשאה, או העברת מפתח לצד שלישי כדי שיעשה בו שימוש אסור, עשויים ליפול לגדרם.
הקשר בין השכבות הוא מעשי: ככל שההרשאה מוגדרת בחוזה בצורה מדויקת יותר, כך קל יותר להראות שפעולה מסוימת נעשתה ״שלא כדין״ או בחריגה מהרשאה.
חשד לחריגה מהרשאה או לדליפת מפתח: מה עושים
- משעים או מחליפים את המפתח, לפי מנגנון ההשעיה שנקבע בהסכם.
- מתעדים את האירוע: בעל מאגר מידע חייב לתעד כל אירוע המעלה חשש לשימוש במידע בלא הרשאה או בחריגה מהרשאה (תקנה 11(א) לתקנות הגנת הפרטיות (אבטחת מידע)).
- שומרים את יומני הגישה. במאגר ברמת אבטחה בינונית או גבוהה הם נשמרים 24 חודשים לפחות (תקנה 10(ד)).
- בודקים אם מדובר ב״אירוע אבטחה חמור״ כהגדרתו בתקנה 1. אם כן, מודיעים על כך לרשות להגנת הפרטיות באופן מיידי (תקנה 11(ד)).
- שולחים למפתח דרישה בכתב לחדול מהשימוש ולמחוק את המידע שנשאב, בהתאם להסכם.
- כשיש חשד לחדירה שלא כדין או לשיבוש, שוקלים תלונה במשטרה לפי חוק המחשבים (סעיפים 2 ו-4).
מידע אישי שעובר בממשק
אם דרך הממשק זורם מידע על בני אדם, נכנסים לתמונה דיני הגנת המידע. לפי חוק הגנת הפרטיות, התשמ״א-1981, כנוסחו לאחר תיקון מס׳ 13 שנכנס לתוקף ב-14 באוגוסט 2025, בעל שליטה הוא מי שקובע את מטרות העיבוד ומחזיק הוא גורם חיצוני שמעבד מידע בעבורו. בממשק שבו המפתח מעבד מידע בעבור המפעיל — המפתח הוא מחזיק; בממשק שבו המפעיל מספק שירות למפתח על מידע של לקוחות המפתח — היחס עשוי להתהפך. קביעת התפקידים במפורש בהסכם חוסכת מחלוקת מאוחרת.
כשההתקשרות כרוכה במתן גישה למאגר מידע, תקנה 15 לתקנות הגנת הפרטיות (אבטחת מידע), התשע״ז-2017 מחייבת לקבוע בהסכם את המידע שמותר לעבד ואת מטרות השימוש, את המערכות שניתן לגשת אליהן, את סוג העיבוד, את משך ההתקשרות ואת אופן השבת המידע והשמדתו בסיומה, את אופן יישום חובות האבטחה, התחייבות בעלי ההרשאות לסודיות, כללים להעסקת ספק משנה, וחובות דיווח — אחת לשנה לפחות, והודעה לבעל המאגר במקרה של אירוע אבטחה. אותה דרישה חלה על כל הסכם ענן או שירות.
אחריות: מי נושא בנזק, ומול מי
בממשק פתוח יש שלושה מעגלי נזק, ולכל אחד הסדר משלו. המעגל הראשון הוא נזק שהמפתח גורם למפעיל — עומס שמפיל את השירות, שימוש חורג בנתונים או פרצה שמקורה בצד שלו. כאן נדרשת התחייבות לשיפוי מצד המפתח, מוגדרת בהיקף ובתקרה, ולצדה זכות השעיה מיידית.
המעגל השני הוא נזק שהמפעיל גורם למפתח — השבתה, שיבוש נתונים או ניתוק פתאומי. כאן מוצע בדרך כלל פטור רחב, והוא שנבחן לפי חוק החוזים האחידים: פטור גורף נכנס לחזקת הקיפוח שבסעיף 4(1), ופטור מאחריות לנזק גוף או למעשה זדון בטל לפי סעיף 5(ב). תקרה מידתית, שמחריגה במפורש זדון, הפרת סודיות והפרת חובות אבטחת מידע, עמידה הרבה יותר.
המעגל השלישי הוא נזק לצד שלישי — משתמש הקצה של המפתח שנפגע מתקלה או מדליפה. במצב כזה שני הצדדים עלולים להיתבע יחד, והשאלה הפנימית היא חלוקת האחריות ביניהם. סעיף שיפוי הדדי, שמחלק את הסיכון לפי מקור הכשל ולא לפי זהות התובע, חוסך התדיינות שנייה. כדאי גם לקבוע מנגנון שיתוף פעולה בהגנה: מי מנהל את ההליך, מי נושא בעלויות ומי רשאי להתפשר.
לצד אלה, כשהממשק מעביר מידע אישי, כדאי לדרוש קיום ביטוח מתאים ולהגדיר את היקפו ואת משך תוקפו גם לאחר סיום ההתקשרות — חשיפה בתחום הזה מתגלה לעתים קרובות באיחור.
קניין רוחני, נתונים ותוצרים
שלוש שאלות בעלות נפרדות, שכדאי שלא יתערבבו. הראשונה: הזכויות בממשק עצמו, בתיעוד ובספריות העזר — נשארות אצל המפעיל, והמפתח מקבל רישיון שימוש מוגבל, בלתי בלעדי ובלתי עביר. השנייה: הנתונים שמועברים דרך הממשק — למי הם שייכים, ומה מותר לעשות בהם אחרי סיום ההתקשרות. השלישית: התוצרים שהמפתח יוצר מעל הממשק — האפליקציה שלו היא שלו, אך ייתכן שיש בה רכיבים שמקורם במפעיל.
סעיף נוסף שמומלץ לכלול: שימוש בשם ובסימני המסחר. מפתחים נוטים להציג את שם המפעיל כדי לשדר אמינות, ומפעילים נוטים להציג את לקוחותיהם. עדיף להסדיר מראש מה מותר להציג, באיזה הקשר, ומתי הרשות פוקעת.
סיום, שינוי והודעה מוקדמת
הסכם ממשק סביר מבחין בין שלושה מצבי סיום: סיום יזום של המפתח; סיום יזום של המפעיל מטעמים מסחריים, שמחייב הודעה מוקדמת סבירה; והשעיה מיידית בשל הפרה, סיכון אבטחתי או דרישת רשות. לכל מצב יש לקבוע מה קורה לנתונים שכבר הועברו: מחיקה, החזרה, או המשך שימוש מוגבל.
לעניין שינוי התנאים — הנוסח הרווח ״המשך השימוש מהווה הסכמה לתנאים המעודכנים״ נבחן בחוזה אחיד לפי חזקות הקיפוח. גרסה מאוזנת קובעת הודעה מראש, מבחינה בין שינוי טכני לשינוי מהותי, ומעניקה למפתח חלון זמן לסיים את ההתקשרות בלי קנס אם השינוי מהותי.
שאלות ותשובות
האם תנאי שימוש ב-API מחייבים אם רק סימנו תיבה?
כן, ככלל. הסכמה יכולה להתגבש באישור אלקטרוני ובשימוש בפועל במפתח הגישה. עם זאת, כשמדובר בנוסח אחיד שהצד החזק כתב מראש, תנאים מסוימים בו עשויים להתבטל או להשתנות לפי חוק החוזים האחידים — ותנאי השולל את הזכות לפנות לערכאות בטל מלכתחילה.
מה קורה אם מפתח חורג ממגבלות הקצב?
אם המגבלות והתוצאה של חריגה נקבעו בחוזה — חלה התוצאה שנקבעה: האטה, חיוב נוסף או השעיה. אם לא נקבעו, המפעיל נותר עם טענות כלליות בלבד, ולעתים עם טענה לפי חוק המחשבים בדבר הפרעה לשימוש במחשב — טענה שקשה יותר להוכיח.
אפשר לסגור גישה למפתח בלי הודעה?
תלוי בעילה ובנוסח. השעיה מיידית בשל הפרה או סיכון אבטחתי היא סבירה; ניתוק מסחרי ללא הודעה, במיוחד כשהמפתח בנה מוצר על הממשק, נבחן לפי חזקת הקיפוח שבסעיף 4(2) לחוק החוזים האחידים. עדיף להגדיר מראש עילות וזמני הודעה.
האם נדרש הסדר פרטיות נפרד לממשק?
אם עובר בו מידע על בני אדם — כן. יש לקבוע מי בעל השליטה ומי המחזיק, ולכלול את הנושאים שמונה תקנה 15 לתקנות הגנת הפרטיות (אבטחת מידע): היקף העיבוד, המערכות, סוג הפעולות, משך ההתקשרות, השבת המידע והשמדתו, יישום חובות האבטחה, סודיות, ספקי משנה ודיווח על אירוע אבטחה.
מה בודקים בפועל
- טיפ פרקטי: בניסוח תנאי ממשק, הפרידו בין ״מדיניות שימוש מקובל״ הניתנת לעדכון שוטף לבין ההסכם עצמו. כך אפשר לעדכן כללים תפעוליים בלי לפתוח את החוזה — ובלבד שההסכם מגדיר מראש את מנגנון העדכון ואת ההודעה.
- מקור נורמטיבי מדויק: הגדרת חוזה אחיד — סעיף 2, תנאי מקפח — סעיף 3, חזקות הקיפוח — סעיף 4 והתנאים הבטלים — סעיף 5, כולם בחוק החוזים האחידים. עבירות החדירה והשיבוש — סעיפים 2, 4, 5 ו-6 לחוק המחשבים. חובות ההסכם במיקור חוץ — תקנה 15 לתקנות הגנת הפרטיות (אבטחת מידע).
- טעות נפוצה: לנסח תנאי ממשק כהסכם רישוי תוכנה סטנדרטי. ברישוי מוסרים עותק; בממשק מוסרים גישה מתמשכת לנתונים חיים — ולכן סעיפי ההרשאה, האבטחה והסיום הם הליבה.
- נקודה טקטית: בסכסוך על שימוש חורג, התיעוד הטכני הוא הראיה. שמירת יומני קריאות, תיעוד מועד ההרשאה והיקפה, ותיעוד ההודעה על החריגה — הם שמבססים את הטענה, בין בעילה חוזית ובין בעילה לפי חוק המחשבים.
מקורות
- חוק החוזים האחידים, התשמ״ג-1982 — סעיפים 2, 3, 4 ו-5
- חוק המחשבים, התשנ״ה-1995 — סעיפים 2, 4, 5 ו-6
- חוק הגנת הפרטיות, התשמ״א-1981 — הגדרות ״בעל שליטה״ ו״מחזיק״, כנוסחן בתיקון מס׳ 13
- תקנות הגנת הפרטיות (אבטחת מידע), התשע״ז-2017 — תקנה 15
- חוק החוזים (חלק כללי), התשל״ג-1973
- חוק החוזים האחידים — הסעיפים שנדונים באתר
הקישורים מפנים לנוסח החקיקה במקור. הנוסח המחייב הוא זה שפורסם בספר החוקים. נבדק בספטמבר 2026.