חשבונית ירוקה ו-Make: חיבור ל-API של Morning צעד אחר צעד

כדי להפיק מסמכים ב-Morning (חשבונית ירוקה) מתוך Make, יוצרים מפתח API בהגדרות של Morning, ובתרחיש שולחים שתי קריאות HTTP: אחת שמחליפה את המפתח בטוקן גישה שתקף לשעה, ואחת שיוצרת את המסמך עם הטוקן. API זמין במסלול Best ומעלה, ויש סביבת בדיקות נפרדת שבה בונים ובודקים בלי להפיק מסמכים אמיתיים (נכון לאוקטובר 2026).

את התהליך הכללי, מתי מפיקים איזה מסמך ומה בודקים מול רואה החשבון, כתבתי במאמר על חשבוניות וקבלות אוטומטיות. כאן אני נכנס לצד הטכני: איך זה בנוי ב-Make, אילו שדות שולחים, ומה עושים כשמשהו נכשל. כל הפרטים נבדקו מול התיעוד הרשמי של Morning באוקטובר 2026. אם המסמך צריך לצאת משינוי סטטוס ב-monday, יש לי גם מאמר על חיבור חשבונית ירוקה ל-monday.

מה צריך להכין ב-Morning לפני שמתחילים?

1. מסלול שכולל API. לפי מרכז העזרה של Morning, מפתחות API זמינים למנויי Best ומעלה. אם המסלול לא כולל API, בקשת הטוקן תחזיר שגיאה בסגנון "unauthorized_client".
2. מפתח API. נכנסים לאזור האישי, ושם לכלים למפתחים ולמפתחות API. לוחצים על הפלוס, נותנים תיאור (למשל "Make"), מאשרים את התנאים ושומרים. מקבלים מזהה (ID) וסוד (secret).
3. מעתיקים את הסוד מיד. לפי Morning, אפשר להעתיק אותו רק ברגע היצירה. אחר כך אי אפשר לראות אותו שוב, וצריך ליצור מפתח חדש.
4. חשבון בסביבת הבדיקות. נרשמים בנפרד ל-sandbox, מקימים שם עסק פיקטיבי, "קונים" בו מסלול Best פיקטיבי דרך "החשבון שלי", ויוצרים מפתח. לכל סביבה יש מפתחות משלה, ומפתח של הסביבה האמיתית לא יעבוד בסביבת הבדיקות.

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

איך עובד האימות ב-API של Morning?

Morning עובדת עם OAuth 2.0 בשיטת client credentials. בפועל זו קריאת POST אחת:

• כתובת: https://api.morning.co/idp/v1/oauth/token (בסביבת הבדיקות: https://api.sandbox.morning.dev/idp/v1/oauth/token).
• גוף JSON עם שלושה שדות: grant_type עם הערך client_credentials, client_id עם מזהה המפתח, ו-client_secret עם הסוד.
• בתשובה חוזרים accessToken, tokenType (Bearer) ו-expiresAt, זמן התפוגה בשניות מאז 1970.

הטוקן תקף לשעה. אחרי זה כל קריאה תחזיר 401, וצריך לבקש טוקן חדש. בכל קריאה אחרת שולחים כותרת Authorization עם הערך Bearer ואחריו הטוקן.

אם נתקלתם במדריך ישן שבו מבקשים טוקן מכתובת אחרת, עבדו לפי התיעוד העדכני של Morning. השיטה השתנתה, ומדריכים ברשת לא תמיד עודכנו.

איך בונים את זה ב-Make, שלב אחרי שלב?

אני מניח שאתם כבר מכירים את הבסיס של Make. אם לא, כדאי להתחיל במבוא שלי ל-Make ובמדריך לבניית התרחיש הראשון.

1. טריגר. מה שמפעיל את ההפקה: webhook מספק הסליקה, שינוי סטטוס ב-monday, שורה חדשה בגיליון.
2. בקשת טוקן. מודול HTTP מסוג Make a request, שיטה POST, הכתובת של הטוקן, גוף מסוג JSON עם שלושת השדות, וסימון לפענוח התשובה (parse response) כדי שה-accessToken יהיה זמין למיפוי.
3. יצירת המסמך. מודול HTTP נוסף, POST לכתובת https://api.greeninvoice.co.il/api/v1/documents (בסביבת הבדיקות: https://sandbox.d.greeninvoice.co.il/api/v1/documents). בכותרות: Content-Type עם application/json, ו-Authorization עם Bearer והטוקן מהשלב הקודם.
4. שמירה בחזרה. מהתשובה לוקחים את id, את number (מספר המסמך) ואת url, ששם יש קישור ל-PDF, וכותבים אותם ב-CRM.

שימו לב ששתי הכתובות שונות: הטוקן מגיע מ-morning.co, והמסמכים נוצרים ב-greeninvoice.co.il. ככה זה מופיע בתיעוד.

לגבי הטוקן, יש שתי דרכים. הפשוטה: לבקש טוקן חדש בכל הרצה. זה עולה מודול אחד נוסף בכל הרצה, ובתרחיש שרץ כמה פעמים ביום זה בסדר. כשיש הרבה הרצות, אני שומר את הטוקן ואת expiresAt ברשומה אחת ב-Data store. בתחילת התרחיש קוראים את הרשומה, ואם נשארו פחות מחמש דקות לתפוגה, מבקשים טוקן חדש ומעדכנים אותה. ב-Make המשתנה timestamp מחזיר את הזמן הנוכחי באותן שניות, כך שההשוואה פשוטה.

אילו שדות שולחים כדי ליצור חשבונית?

לפי התיעוד, חמישה שדות חובה: type (סוג המסמך), lang (he או en), currency (למשל ILS), vatType ו-income (שורות ההכנסה). במסמכים שמאשרים תשלום, כמו קבלה וחשבונית מס קבלה, צריך גם payment.

קוד	סוג המסמך
300	חשבון עסקה
305	חשבונית מס
320	חשבונית מס קבלה
330	חשבונית זיכוי
400	קבלה
405	קבלה על תרומה

בתוך הבקשה:

• client: שם, מיילים (emails), מספר עוסק או ח"פ (taxId), טלפון וכתובת. Morning שולחת קישור למסמך לכתובות שב-emails. אם הלקוח כבר קיים ב-Morning, אפשר לשלוח את ה-id שלו. השדה add מוסיף לקוח חדש לרשימת הלקוחות.
• income: לכל שורה תיאור, כמות, מחיר, מטבע ו-vatType. בשורה, 0 אומר שהמע"מ יתווסף למחיר, 1 שהמחיר כבר כולל מע"מ, ו-2 שהשורה פטורה. כדאי להחליט מראש איך המחיר מגיע מהמערכת שלכם, כי זו טעות נפוצה.
• vatType ברמת המסמך: 0 ברירת מחדל לפי סוג העסק, 1 פטור, 2 מעורב.
• payment: תאריך, סוג תשלום, סכום ומטבע. קודי סוג התשלום: 1 מזומן, 2 צ'ק, 3 כרטיס אשראי, 4 העברה בנקאית, 10 אפליקציית תשלום (ואז appType 1 הוא Bit), 11 אחר.

כך נראית בקשה לחשבונית מס קבלה על העברה בנקאית, לפי שמות השדות בתיעוד:

{
  "type": 320,
  "lang": "he",
  "currency": "ILS",
  "vatType": 0,
  "client": {
    "name": "ישראל ישראלי",
    "emails": ["[email protected]"],
    "taxId": "123456789",
    "add": true
  },
  "income": [
    {
      "description": "ליווי חודשי",
      "quantity": 1,
      "price": 1180,
      "currency": "ILS",
      "vatType": 1
    }
  ],
  "payment": [
    {
      "date": "2026-10-26",
      "type": 4,
      "price": 1180,
      "currency": "ILS"
    }
  ]
}

הסכומים כאן הם דוגמה. מה שחשוב הוא שסכום שורות התשלום יהיה שווה לסכום המסמך. אם לא, Morning מחזירה שגיאה 2422 על חוסר התאמה בין התקבולים לתשלומים.

יש אפליקציה מוכנה של Morning ב-Make?

בספריית האפליקציות של Make יש שתי אפליקציות ל-Morning, ושתיהן אפליקציות קהילתיות של שותפים: אחת מתוחזקת על ידי Callbox ומסומנת כאפליקציה שדורשת תשלום לצד שלישי, והשנייה על ידי MAXMEL Tech (נכון לאוקטובר 2026). הן לא של Make ולא של Morning.

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

מה עושים כשהקריאה נכשלת?

השגיאות של Morning מגיעות עם קוד מספרי והודעה בעברית. כמה שכדאי להכיר: 2403 (סוג מסמך לא נתמך לסוג העסק, למשל חשבונית מס אצל עוסק פטור), 2419 (חסרה שורת תקבולים), 2422 (סכומים לא תואמים), 1012 (הפעולה דורשת מסלול גבוה יותר).

ב-Make אני מחבר לכל מודול HTTP מטפל שגיאות (error handler), ומבדיל בין שני המודולים:

• בקשת הטוקן בטוחה לניסיון חוזר. כאן מתאים Break עם ניסיונות חוזרים אוטומטיים, שדורש להפעיל בהגדרות התרחיש שמירה של הרצות שלא הושלמו (incomplete executions).
• יצירת המסמך לא בטוחה לניסיון חוזר עיוור. אם הבקשה נפלה על timeout, ייתכן שהמסמך דווקא נוצר, וניסיון נוסף יפיק מסמך שני. לכן במודול הזה אני מעדכן ב-CRM סטטוס "שגיאה בהפקה", שולח לעצמי התראה עם הודעת השגיאה, ובודק ידנית לפני שמריצים שוב.

עוד דבר: התשובה ליצירת מסמך כוללת שדות על אישור מרשות המסים (taxAuthorityConfirmationInitiated ו-taxAuthorityConfirmationLastError). אם אתם מפיקים חשבוניות מס ללקוחות עסקיים שצריכות מספר הקצאה, כדאי לשמור גם אותם ולהתריע כשקוד השגיאה שונה מאפס.

איך מקבלים עדכונים מ-Morning בחזרה ל-Make?

ל-Morning יש webhooks, והם מוגדרים בממשק ולא דרך ה-API: בכלים למפתחים נכנסים ל-Webhooks, מוסיפים webhook, מדביקים את הכתובת של Custom webhook מ-Make ובוחרים אירועים. האירועים השימושיים: document/created כשנוצר מסמך, ו-payment/received כשמתקבל תשלום. יש גם אירוע על לקוח חדש ועל הזמנה ששולמה בדף מכירה.

זה מה שמאפשר לסנכרן מסמכים שמישהו הפיק ידנית ב-Morning, כמו קבלה על מזומן, בחזרה ל-CRM. כמה דברים מהתיעוד:

• סוג האירוע מגיע בכותרת x-webhook-topic. אני מעדיף webhook נפרד לכל אירוע, ככה כל תרחיש מטפל בדבר אחד.
• שדות בלי ערך לא נשלחים בכלל. בתרחיש צריך להניח שכל שדה יכול להיות חסר.
• אפשר להגדיר סוד, ואז כל משלוח חתום ב-HMAC-SHA256 בכותרת x-webhook-signature.
• התשובה צריכה להיות 200, 201, 202 או 204. אחרי 15 כישלונות ה-webhook הופך ללא פעיל ומפסיק לשלוח. אם תרחיש נכבה או נשבר, כדאי לבדוק אחר כך שה-webhook ב-Morning עדיין פעיל.

איך שומרים על המפתחות?

הסוד של המפתח מאפשר להפיק מסמכי מס בשם העסק, ולכן מתייחסים אליו כמו לסיסמה. אני לא מקליד אותו בגלוי בתוך כל תרחיש. שומרים אותו במקום אחד, ברשומה ב-Data store או במשתנה מותאם של הצוות, וממפים ממנו. כך מי שמקבל גישה לתרחיש או ל-blueprint שלו לא רואה את הסוד, ואם צריך להחליף מפתח, מחליפים במקום אחד.

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

שאלות נפוצות

באיזה מסלול של Morning יש גישה ל-API?

לפי מרכז העזרה של Morning, מפתחות API זמינים למנויי Best ומעלה (נכון לאוקטובר 2026). כדאי לבדוק את המחיר העדכני באתר שלהם.

כמה זמן תקף הטוקן של Morning?

שעה. התשובה כוללת את expiresAt, וכשהוא עובר כל קריאה מחזירה 401 וצריך לבקש טוקן חדש.

אפשר לחבר את Morning ל-Make בלי לכתוב קוד?

כן. מודולי HTTP ב-Make מספיקים, וצריך רק למלא כתובת, כותרות וגוף JSON. מה שדורש הבנה הוא השדות של המסמך, ובעיקר סוג המסמך, המע"מ והתשלומים.

איך בודקים בלי להפיק מסמכים אמיתיים?

בסביבת ה-sandbox של Morning, עם מפתחות נפרדים וכתובות נפרדות. כשהכול עובד, מחליפים את הכתובות והמפתחות לסביבה האמיתית, ועוברים ידנית על המסמכים הראשונים.

מה ההבדל בין קוד 320 לקוד 305?

320 הוא חשבונית מס קבלה, כשהתשלום כבר התקבל, ולכן צריך בו שורות תשלום. 305 הוא חשבונית מס בלי קבלה. איזה מהם מתאים לעסק שלכם, זו שאלה לרואה החשבון.

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

עודכן לאחרונה: אוקטובר 2026