תחשבו על שלושה סוגי קשר עם ספק. Webhook: הספק מתקשר כשהמשלוח יצא. Polling: אתם מתקשרים אליו כל שעה לשאול. API: התפריט של מה מותר לכם לבקש ממנו בטלפון. חיבור טוב משתמש בראשון ובשלישי.
← לכל המדריכיםINTEGRATIONS
Webhook, API או Make: מה זה כל אחד, ומתי עסק קטן צריך קוד
Webhook זה כשהמערכת מתקשרת אליכם. API זה תפריט של דברים שאתם יכולים לבקש ממנה. ברגע שההבדל הזה ברור, השאלה ׳Make או מתכנת׳ נהיית שאלה של מספרים.
המדריך הזה מבוסס על תיעוד ה-HTTP של MDN, על התיעוד של Make, n8n ו-Zapier ל-webhooks, ועל התיעוד של Meta לאימות webhooks, לצד חיבורים שבניתי לעסקים קטנים בכלים ובקוד. הוא מיועד לבעל עסק שמישהו הציע לו ׳לחבר את המערכות׳, למי שכבר בונה ב-Make או n8n ונתקע, ולמפתח שצריך להחליט מה נכנס לקוד ומה נשאר בכלי.
להתחיל לקרוא ↓01 · שלוש מיליםלמי שרק מתחיל למי שכבר משתמש לטכניים מקור רשמי: Make, Webhooks ↗
Webhook, polling ו-API, על דוגמה אחת
ליד ממלא טופס באתר. Webhook: הטופס שולח את הפרטים לכתובת שלכם ברגע הלחיצה. Polling: אתם שואלים את הטופס כל חמש דקות אם יש משהו חדש. API: התפריט שדרכו אתם מבקשים מה-CRM ליצור את הליד. שלושתם משתתפים באותו חיבור.
טופס נשלח←webhook מגיע←עיבוד←קריאת API ל-CRM
Webhook הוא הסדר ההפוך מהרגיל: במקום שאתם תפנו למערכת, המערכת פונה אליכם. אתם נותנים לה כתובת, והיא שולחת לשם הודעה בכל פעם שקורה משהו. ב-Make זה Custom webhook, ב-n8n זה Webhook node, ב-Zapier זה Catch Hook.
Polling הוא הגרסה הישנה: הכלי שואל את המקור כל כמה דקות אם יש חדש. זה עובד עם מערכות שלא יודעות לשלוח webhook, אבל משלם בעיכוב ובפעולות שנשרפות כשאין כלום. API הוא רשימת הפעולות שמערכת מאפשרת מבחוץ, למשל ׳צור איש קשר׳. ה-webhook מביא את האירוע, ה-API מבצע את התגובה.
כשמחפשים טריגר ב-Make או n8n, תעדיפו Instant או Webhook על פני Scheduled או Polling לאירועים שצריך להגיב להם מיד. Polling מתאים לדברים שמשתנים לאט, כמו סנכרון יומי של רשימת מוצרים.
שלושתם הם HTTP. Webhook הוא POST שהמקור מבצע לכתובת שלכם עם גוף JSON. Polling הוא GET שאתם מבצעים למקור בלולאה. API הוא אוסף כתובות ומתודות שהמקור מתעד. ההבדל הוא מי יוזם ומתי, וזה מה שקובע עיכוב ועלות.
02 · על החוט
מקור רשמי: MDN, HTTP response status codes ↗
איך בקשת HTTP נראית, ומה הקודים אומרים
כל בקשה מכילה מתודה (GET, POST), כתובת, כותרות, ולפעמים גוף. כל תשובה מכילה קוד סטטוס בין 100 ל-599, וגם היא כותרות וגוף. הגוף כמעט תמיד JSON: טקסט עם שדות וערכים. מי שיודע לקרוא את ארבעת החלקים האלה יכול לדבג כל אוטומציה.
לפי MDN, HTTP הוא פרוטוקול של בקשה ותשובה, והוא חסר זיכרון: אין קשר בין שתי בקשות עוקבות. כל בקשה נושאת בעצמה את כל מה שהשרת צריך, כולל ההזדהות. זו הסיבה שמפתח API נשלח בכל בקשה.
המתודות שתפגשו: GET מבקש נתונים ולא אמור לשנות כלום. POST שולח נתונים ובדרך כלל יוצר משהו. PUT מחליף רשומה שלמה, PATCH משנה חלק ממנה, DELETE מוחק. ההבדל בין POST לשאר יהיה חשוב כשנדבר על ניסיונות חוזרים.
| קוד | מה זה אומר | מה עושים |
|---|---|---|
| 200 או 201 | הצליח. 201 אומר שנוצרה רשומה חדשה | כלום. זה המצב הרגיל |
| 400 | הבקשה לא תקינה: שדה חסר, JSON שבור, פורמט שגוי | תתקנו את הנתונים. ניסיון חוזר לא יעזור |
| 401 או 403 | לא מזוהים, או מזוהים בלי הרשאה | מפתח API פג או שגוי. תחליפו אותו במקום לנסות שוב |
| 404 | הכתובת או הרשומה לא קיימים | תבדקו את ה-URL ואת המזהה. לפעמים הרשומה פשוט נמחקה |
| 429 | יותר מדי בקשות בפרק זמן | תחכו לפי הכותרת Retry-After ותנסו שוב |
| 500, 502, 503, 504 | בעיה בצד השרת, לרוב זמנית | ניסיון חוזר עם המתנה גדלה. אם זה נמשך, זה לא אתם |
03 · מתי כלילמי שרק מתחיל למי שכבר משתמש לטכניים מקור רשמי: n8n, Webhook node ↗
מתי Make, n8n או Zapier הם התשובה הנכונה
כשיש מעט שלבים, כשלמערכות בשני הצדדים יש אינטגרציה מוכנה, וכשמי שיתחזק את זה בעוד שנה הוא לא מתכנת. שלושת התנאים ביחד. ברוב העסקים הקטנים הם מתקיימים ברוב החיבורים, ולכן ברוב המקרים הכלי מנצח.
היתרון של הכלים הוא שכל שלב נראה על המסך, שהלוג מראה מה נכנס ומה יצא, ושמישהו שלא בנה את זה יכול לפתוח ולהבין. טופס שנכנס ל-CRM עם הודעת וואטסאפ לבעלים הוא בדיוק המקרה: שלושה מודולים, אפס קוד.
יש גם מגבלות שכתובות בתיעוד. Make מתעדים תור ל-webhooks ומגבלה של 300 בקשות נכנסות לכל עשר שניות, ומעבר לזה 429. Zapier מתעדים ש-webhooks זמינים רק בתוכניות בתשלום. n8n מתעדים מטען מקסימלי של 16MB ל-Webhook node. לעסק קטן המספרים האלה רחוקים, אבל הם קיימים.
אם מישהו מציע לכם לכתוב קוד בשביל לחבר טופס ל-CRM, תשאלו למה זה לא נעשה ב-Make. יש תשובות טובות, והן בסעיף הבא. ׳ככה אני רגיל׳ היא לא אחת מהן.
תבדקו שהאינטגרציה המוכנה כוללת את הפעולה שצריך, למשל ׳חפש לפי טלפון׳, ולא רק ׳צור׳. אם היא חסרה, רוב הכלים מאפשרים לקרוא ל-API ישירות דרך מודול HTTP, ואז אתם עובדים עם התיעוד של ה-API.
ה-Webhook node של n8n תומך ב-Basic auth, Header auth ו-JWT, ומאפשר רשימת IP מורשים שמחזירה 403 לכל השאר. ב-Zapier התיעוד מציין שכתובת ה-webhook מכילה את המזהה שלכם, ולכן היא סוד: לא בקוד שרץ בדפדפן.
04 · מתי קודלמי שרק מתחיל למי שכבר משתמש לטכניים
חמישה מצבים שבהם כמה שורות קוד מנצחות
נפח גבוה, עיצוב נתונים מסובך, דרישות אבטחה, עלות שמטפסת עם כל פעולה, ומערכת שאין לה אינטגרציה בשום כלי. מספיק אחד מהחמישה כדי שקוד יהיה זול ופשוט יותר. שניים, ואין דיון.
- נפח: כלי אוטומציה מתמחרים לפי פעולות. חיבור שרץ עשר פעמים ביום לא מרגיש את זה. חיבור שרץ עשרת אלפים פעמים ביום הופך את החשבונית לסעיף בתקציב
- עיצוב נתונים: לפרק JSON מקונן, לאחד שלושה מקורות, לחשב משהו על היסטוריה. בכלי זה עשרים מודולים שאף אחד לא יבין. בקוד זה עשרים שורות
- אבטחה: אימות חתימה על webhook נכנס, מידע רגיש שאסור שיעבור דרך צד שלישי, או דרישה שהנתונים לא יצאו מהשרת שלכם
- עלות בקנה מידה: כשמספר הפעולות גדל, המחיר של הכלי גדל איתו. פונקציה בענן מתומחרת לפי שימוש בפועל
- אינטגרציה שאף אחד לא מציע: מערכת ישראלית ותיקה, תוכנה מקומית, קובץ שמגיע ב-FTP. אין מודול מוכן, אז ממילא עובדים עם ה-API הגולמי
קוד לא אומר פרויקט של חודשים. במקרים האלה מדובר בקובץ אחד, כמה עשרות שורות, שרץ בענן ומקבל בקשות. השאלה לשאול את מי שכותב אותו: מי מתחזק את זה כשהוא לא זמין, ואיפה זה מתועד.
סימן שהגעתם לגבול הכלי: תרחיש עם יותר מחמישה עשר מודולים, או כזה שאתם מפחדים לגעת בו. זה הרגע לשאול איזה חלק ממנו הופך לפונקציה אחת.
הטיעון החזק ביותר לקוד הוא בדיקות. פונקציה עם קלט ופלט ברורים אפשר לבדוק על עשרה מקרי קצה לפני שהיא נוגעת בנתונים אמיתיים. תרחיש בכלי בודקים בפרודקשן, על ליד אמיתי.
05 · דרך האמצע
פונקציה קטנה שהכלי קורא לה
משאירים את הזרימה ב-Make או n8n, ומוציאים רק את החלק המסובך לפונקציה קטנה בענן. הכלי שולח לה JSON דרך מודול HTTP, היא מחזירה JSON נקי, והזרימה ממשיכה. מי שלא מתכנת עדיין רואה את כל התהליך על המסך.
זו הצורה שרוב החיבורים שבניתי מגיעים אליה אחרי כמה חודשים. הטריגר, ההודעות והחיבור ל-CRM נשארים בכלי, כי שם הם קריאים. הנורמליזציה של הטלפון או בדיקת הכפילות מול שני מקורות עוברות לפונקציה. n8n מציעים גם Code node ל-JavaScript או Python בתוך הזרימה, אבל לפי התיעוד שלהם אי אפשר לבצע ממנו בקשות HTTP או לגשת לקבצים. לחלקים שצריכים לדבר עם העולם, פונקציה חיצונית.
׳בענן׳ כאן זה serverless: שירותים כמו Azure Functions ודומיהם, שבהם מעלים קוד בלי לנהל שרת. הקוד מתעורר כשמגיעה בקשה, רץ, ונרדם. לחיבור שרץ כמה מאות פעמים ביום זה בדרך כלל זול מכל חלופה.
- תסמנו בתרחיש הקיים את הקטע שכולם מפחדים ממנו, ותכתבו במשפט אחד מה נכנס אליו ומה יוצא ממנו
- תכתבו פונקציה אחת שמקבלת POST עם JSON בצורה הזאת ומחזירה JSON בצורה הזאת, וכלום מעבר
- תוסיפו לה אימות: כותרת עם סוד שרק הכלי שלכם מכיר
- תחליפו את הקטע במודול HTTP אחד שקורא לפונקציה, ותריצו את שני המסלולים במקביל על אותם נתונים יום אחד
- תתעדו בהערה ליד המודול איפה הקוד חי ומי מתחזק אותו
06 · טבלת החלטה
כלי, קוד, או שניהם: לפי מה מחליטים
תענו על שש שאלות: כמה פעמים ביום זה רץ, כמה שלבים, האם יש אינטגרציה מוכנה, מי מתחזק, מה רגישות הנתונים, וכמה זה עולה בעוד שנה. הטבלה נותנת תשובה לכל שורה. אם רוב השורות מצביעות לכיוון אחד, זו התשובה.
רוב החיבורים של עסק קטן נופלים ב׳כלי בלבד׳, וזה בסדר. העמודה האמצעית היא לחיבור אחד או שניים שגדלו. השורה שמכריעה בפועל היא התחזוקה: קוד בלי בעלים מת מהר יותר מתרחיש בלי בעלים, כי אף אחד לא רואה אותו.
| השאלה | כלי בלבד | כלי ופונקציה | קוד בלבד |
|---|---|---|---|
| כמה הרצות ביום | עד מאות | מאות עד אלפים | אלפים ומעלה, או תגובה בזמן אמת |
| כמה שלבים בזרימה | עד עשרה | עשרה ומעלה, עם קטע אחד מסובך | לוגיקה שקשה לצייר כשלבים |
| יש אינטגרציה מוכנה לשני הצדדים | כן | לאחד הצדדים | לאף אחד |
| מי מתחזק בעוד שנה | מישהו בצוות שלא מתכנת | הצוות מתפעל, מתכנת בקריאה | מתכנת זמין באופן קבוע |
| רגישות הנתונים | רגילה | החלק הרגיש עובר רק בפונקציה | רגיש, או דרישה שלא יצא מהשרת |
| עלות בעוד שנה | פחות ממשכורת של יום בחודש | מתחילה לכאוב בחשבונית | הכלי יקר מהתחזוקה |
07 · מה מחזיקלמי שרק מתחיל למי שכבר משתמש לטכניים
חתימה, ניסיונות חוזרים, מגבלות קצב וסודות
ארבעה דברים מפרידים בין חיבור שעובד בדמו לחיבור שמחזיק שנה: אימות שההודעה באמת הגיעה ממי שטוען, טיפול בהודעה שמגיעה פעמיים, כבוד למגבלות הקצב של הצד השני, וסודות שלא חיים בתוך התרחיש. כולם קטנים. על כולם מדלגים.
חתימה. כתובת webhook היא ציבורית מרגע שהיא קיימת. Meta, למשל, מצרפים לכל webhook כותרת X-Hub-Signature-256: חתימת HMAC עם SHA256 על גוף הבקשה, עם ה-app secret שלכם. אם החתימה שחישבתם תואמת, ההודעה אמיתית. מי שלא בודק מקבל לידים מכל מי שמצא את הכתובת.
ניסיונות חוזרים. Meta מתעדים שאם הכתובת לא מחזירה 200, הם מנסים שוב, בתדירות יורדת. המשמעות: אותה הודעה תגיע פעמיים, וחיבור טוב מזהה את זה לפי מזהה ההודעה. בכיוון השני, MDN מסבירים ש-GET, PUT ו-DELETE בטוחים לחזרה, ו-POST לא מובטח. לכן ספקים רבים מקבלים מפתח idempotency: מזהה שמצרפים לבקשה, כדי שבקשה חוזרת לא תיצור רשומה שנייה.
מגבלות קצב. תשובה 429 אומרת ׳יותר מדי בקשות׳, ולפעמים מגיעה עם כותרת Retry-After שאומרת כמה לחכות. חיבור שמנסה שוב מיד רק מאריך את החסימה. חיבור שמגדיל את ההמתנה בכל כישלון עובר את זה בשקט.
תשאלו את מי שבנה לכם את החיבור שתי שאלות: מה קורה אם אותה הודעה מגיעה פעמיים, ואיפה שמורים הסיסמאות והמפתחות. תשובה מגומגמת על אחת מהן היא סיבה לבדוק לעומק.
בכלי, כפילויות פותרים עם ׳חפש לפי מזהה׳ לפני ׳צור׳. סודות שומרים בחיבורים (Connections או Credentials) של הכלי, אף פעם לא כטקסט בתוך מודול. וכשמעבדים רשימה ארוכה, תוסיפו השהיה בין פריטים.
בפונקציה: בודקים חתימה לפני שמפרסרים JSON, מחזירים 200 מהר ומעבדים אחר כך, שומרים מזהי הודעות שטופלו, ומטפלים ב-429 ו-5xx עם המתנה מעריכית ומספר ניסיונות מוגבל. סודות במשתני סביבה או בכספת של ספק הענן, אף פעם לא בקוד ולא בלוג.
פרומפט לכתיבת מפרט לפונקציה קטנה
מקור רשמי: Meta, Webhooks getting started ↗אני צריך מפרט קצר לפונקציה שרצה בענן ומקבלת webhook. המערכת ששולחת: [השלם את המידע כאן: מי שולח, למשל טופס באתר או WhatsApp] מה הפונקציה צריכה לעשות: [השלם את המידע כאן: למשל לנרמל טלפון ולבדוק כפילות] לאן היא כותבת בסוף: [השלם את המידע כאן: מערכת היעד וה-API שלה] תכתוב מפרט בעברית שכולל: מבנה ה-JSON הנכנס והיוצא, איך מאמתים שהבקשה אמיתית, מה קורה כשאותה הודעה מגיעה פעמיים, איך מטפלים ב-429 וב-5xx, איפה נשמרים הסודות, ומה נרשם ללוג. תסיים ברשימה של שמונה מקרי בדיקה, כולל שלושה מקרי קצה עם קלט שבור. אם חסר לך מידע, תשאל לפני שאתה כותב.
08 · מחר בבוקרלמי שרק מתחיל למי שכבר משתמש לטכניים
מה עושים עם זה מחר בבוקר
תיקחו את החיבור הכי חשוב שרץ אצלכם ותענו על שש השאלות בטבלה. אחר כך תשאלו: מה קורה כשהודעה מגיעה פעמיים, ואיפה הסודות. ברוב העסקים זה לוקח חצי שעה, ומגלה חיבור אחד שצריך פונקציה, או סוד אחד שיושב בתוך מודול.
- תכתבו לכל חיבור פעיל: טריגר (webhook או polling), מספר הרצות ביום, ומי מתחזק
- תפתחו את הלוג של החיבור ותחפשו 429 ו-5xx מהחודש האחרון. אם יש, תבדקו מה קרה לנתונים באותן הרצות
- תמצאו כל מפתח API שיושב כטקסט בתוך תרחיש, ותעבירו אותו לחיבור מאובטח של הכלי
תבקשו ממי שבנה לכם את החיבורים דף אחד: מה מחובר למה, איך, ולמי מתקשרים כשזה נופל. אם אין דף כזה, זו המשימה הראשונה.
תבחרו תרחיש אחד ארוך ותסמנו בו את הקטע שהייתם מוציאים לפונקציה. גם אם לא תעשו את זה החודש, הסימון מבהיר איפה הסיבוך יושב.
תכתבו פונקציית webhook אחת גנרית: מאמתת חתימה, שומרת מזהה, מחזירה 200, ומעבירה הלאה. כל חיבור חדש הוא שכפול עם עשר שורות שונות, וכל תיקון אבטחה קורה במקום אחד.
לפני שמחליפים כלימי שנתקע ב-Make עובר ל-n8n, ומי שנתקע ב-n8n כותב קוד, והבעיה נשארת: אין הגדרה של מה נכנס, מה יוצא, ומה קורה כשזה נופל. תגדירו את זה קודם, ואולי תגלו שהכלי הקיים מספיק.
שאלות שחוזרות
שאלות שאני שומע על זה
מה ההבדל בין webhook ל-API במשפט אחד?
Webhook: המערכת שולחת לכם הודעה כשמשהו קורה. API: רשימת הפעולות שאתם יכולים לבקש מהמערכת. ברוב החיבורים משתמשים בשניהם, webhook לקבל את האירוע ו-API לבצע את התגובה.
Make, n8n או Zapier לחיבור עם webhook?
שלושתם תומכים ב-webhooks נכנסים ויוצאים. Zapier מתעדים שזה זמין רק בתוכניות בתשלום. n8n מציעים גם התקנה עצמית על תשתית משלכם, ואז אתם מתחזקים את השרת.
צריך מתכנת כדי לאבטח webhook?
לאימות חתימה של הספק, כן, זה קוד. בכלי אפשר להגיע לרמה סבירה: כתובת webhook שלא מתפרסמת, אימות בכותרת או רשימת IP ב-n8n, ושלב ׳חפש לפני צור׳ נגד כפילויות. לנתונים רגישים, פונקציה קטנה שמאמתת חתימה שווה את ההשקעה.
מקורות רשמיים
- MDN, An overview of HTTP
- MDN, HTTP request methods
- MDN, HTTP response status codes
- MDN, 429 Too Many Requests
- MDN, Idempotent
- MDN, JSON
- Make, Webhooks
- n8n, Webhook node
- n8n, Code node
- n8n, Host n8n
- Zapier, Trigger Zap workflows from webhooks
- Zapier, Send webhooks in Zap workflows
- Meta, Webhooks getting started
- Microsoft Learn, Azure Functions overview