API (ראשי תיבות של Application Programming Interface) הוא דרך מוסכמת שבה תוכנה אחת מבקשת משהו מתוכנה אחרת — ומקבלת תשובה. אם האתר שלכם צריך לסלוק כרטיס אשראי, לשלוח ליד למערכת ניהול לקוחות, להציג זמינות ביומן או לפרסם פוסט ברשת חברתית — כמעט תמיד זה קורה דרך API. ההגדרה ב-MDN מתארת את זה כסט של פונקציות ונהלים שמאפשרים לבנות תוכנה שמשתמשת בשירות אחר. במאמר הזה אסביר מה זה API ומה זה Webhook בשפה של בעל עסק, ומה כדאי לשאול לפני שמחברים מערכות.
הדימוי הפשוט: מלצר
אתם (האתר) לא נכנסים למטבח (המערכת של הספק). אתם מוסרים הזמנה למלצר בפורמט קבוע — מה רוצים, בכמה, לאיזה שולחן — והוא חוזר עם המנה או עם הודעה ש"נגמר". ה-API הוא המלצר והתפריט יחד: הוא מגדיר מה אפשר לבקש, איך לבקש, ומה חוזר.
איך נראית בקשה
ברוב השירותים המודרניים, בקשת API היא בקשת אינטרנט רגילה (HTTP) לכתובת מסוימת, עם מפתח שמזהה אתכם ונתונים בפורמט JSON. למשל, שליחת ליד מטופס באתר למערכת אחרת יכולה להיראות בערך כך:
POST https://api.example-crm.com/v1/leads
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{"name": "Dana", "phone": "050-0000000", "source": "website"}
והמערכת עונה בקוד סטטוס (למשל 201 — נוצר, או 401 — המפתח לא תקין) ובנתונים על מה שנוצר. אתם לא צריכים לכתוב את זה בעצמכם — אבל כדאי לדעת שזה מה שקורה מאחורי "החיבור".
API מול Webhook
| API | Webhook | |
|---|---|---|
| מי יוזם | האתר שלכם פונה לשירות | השירות פונה לאתר שלכם |
| מתי | כשאתם צריכים משהו | כשמשהו קרה אצל השירות |
| דוגמה | "צור עסקה בסליקה" | "התשלום אושר" — הודעה שמגיעה לאתר |
| הדימוי | להתקשר ולשאול | לקבל הודעה כשיש חדש |
רוב החיבורים הטובים משתמשים בשניהם. בסליקה, למשל, האתר יוצר עסקה דרך API, וחברת הסליקה מודיעה דרך Webhook שהתשלום עבר — ורק אז ההזמנה מסומנת כמשולמת. אתר שמסתמך רק על "הלקוח חזר לעמוד התודה" יפספס תשלומים של מי שסגר את הדפדפן באמצע.
דוגמה מהעבודה שלי: WebGPT
בWebGPT, הפלטפורמה שבניתי, כמעט כל פיצ'ר הוא חיבור API. המערכת מתחברת לשישה ספקי בינה מלאכותית — OpenAI, Gemini, Claude, DeepSeek, Grok ו-Mistral — ולשמונה פלטפורמות פרסום ויותר, ביניהן WordPress, Blogger, Telegram, Facebook, X, LinkedIn, Pinterest ו-TikTok. כמה דברים שלמדתי מזה:
- כל ספק שונה. אותו רעיון — "שלח טקסט, קבל תשובה" — ממומש אחרת אצל כל ספק: פורמט אחר, שגיאות אחרות, מגבלות קצב אחרות. לכן בניתי שכבה אחת שמתרגמת, ולא קוד נפרד בכל מקום שמשתמש בספק.
- ממשקים משתנים. ספקים מעדכנים גרסאות, משנים שדות ומוציאים מודלים מהשירות. חיבור שעבד לפני שנה צריך תחזוקה.
- מגבלות קצב. לרוב השירותים יש תקרה של בקשות לדקה. חיבור שלא מכבד אותה נחסם — בדיוק ביום העמוס.
- תקלות הן מצב רגיל. שירות חיצוני יכול להיות למטה. החיבור צריך לנסות שוב, לרשום את התקלה, ולא להפיל את האתר כולו.
מה לשאול לפני שמחברים מערכת
- יש לשירות API מתועד? בלי תיעוד, כל חיבור הוא ניחוש.
- יש Webhooks לאירועים שחשובים לכם (תשלום, ביטול, ליד חדש)?
- מה העלות? יש שירותים שגובים לפי מספר בקשות, או פותחים API רק בחבילות גבוהות.
- מה המגבלות? כמה בקשות, כמה רשומות, באיזה קצב.
- מי מחזיק את המפתחות? מפתח API הוא כמו סיסמה. הוא צריך להיות בחשבון של העסק, שמור בצד השרת — לעולם לא בקוד שהדפדפן רואה.
- מה קורה כשהחיבור נכשל? מי מקבל התראה, והאם הנתון נשמר כדי לשלוח שוב?
כלים בלי קוד — מתי זה מספיק
שירותים כמו Zapier ו-Make מחברים בין מערכות בלי לכתוב קוד: "כשנשלח טופס — צור איש קשר". לחיבור פשוט עם כמות קטנה של נתונים זה פתרון טוב ומהיר. כשיש לוגיקה מורכבת, כמויות גדולות, דרישות אבטחה או צורך שהחיבור יהיה חלק מהאתר עצמו — חיבור ישיר בקוד יציב יותר וזול יותר לאורך זמן.
אבטחה ופרטיות
כל חיבור API מעביר מידע, ולפעמים מידע אישי של לקוחות. כדאי לדעת לאן הנתונים הולכים, לחבר רק את השדות הנחוצים, ולוודא שהחיבור מוצפן (HTTPS). על הצד הזה הרחבתי במאמר אבטחת מידע לעסק קטן.
דוגמה נפוצה לחיבור כזה היא צ'אטבוט לאתר, שעונה לגולשים מתוך המידע של העסק.
מאמרים קשורים: REST API של וורדפרס: מה אפשר לעשות איתו ואיך שומרים על האתר מאובטח.
מאמרים קשורים: מה זה JSON? הפורמט שבו מערכות מעבירות נתונים.
חיבורים כאלה — לסליקה, למערכות ניהול לקוחות, ליומנים ולשירותים חיצוניים — הם חלק משירות האינטגרציות שלי. אם אתם שוקלים מערכת לניהול פניות, כדאי לקרוא גם מה זה CRM וסליקה באתר. ספרו לי מה אתם רוצים לחבר.
אהבתם את המאמר?
