לחבר את iCount (איקאונט) לסוכני AI ואוטומציות: מדריך כן של מפתח

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

איך iCount באמת חושפת נתונים

ל-iCount יש REST API אמיתי שמחזיר JSON. בפועל יש שני דורות שלו שחיים זה לצד זה. הישן מקבל את מזהה החברה (cid), שם המשתמש והסיסמה כפרמטרים בכל בקשה לכתובות בסגנון PHP. החדש, v3 (api-v3.icount.co.il), נקי יותר: מתחברים פעם אחת ומקבלים טוקן סשן (sid), או משתמשים בטוקן API שהונפק כ-Bearer בכותרת, ואז קוראים לקבוצות משאבים כמו מסמכים (documents) ולקוחות (clients).

כמה דברים באמת משנים בפרקטיקה, ועדיף שתשמעו אותם מראש ולא תגלו אותם בפרודקשן:

• האימות מבוסס סיסמה או טוקן, לא OAuth - ולכן שומרים את הסודות בצד השרת ומסובבים אותם בזהירות. אף פעם לא שמים את פרטי iCount בדפדפן או בשלב no-code חשוף.
• כל תשובה נושאת שדה status/error. iCount יכולה להחזיר HTTP 200 עם שגיאה בתוך הגוף, אז בודקים את התוכן ולא רק את קוד הסטטוס.
• יש מגבלת קצב של בערך 30 בקשות לדקה. סביר לאירועים בודדים, קטלני ללולאות bulk תמימות. צריך לאגד בקשות ולהאט.
• אין מערכת webhook ציבורית אמינה ל'חשבונית חדשה' או 'תשלום התקבל'. זו העובדה הארכיטקטונית הכי חשובה: ברוב המקרים מבצעים polling לפי לוח זמנים במקום לקבל אירועים בדחיפה.

השאלה אף פעם אינה 'האם ל-iCount יש API' - יש. השאלה האמיתית היא 'דחיפה או משיכה', ובמקרה של iCount התשובה הכנה היא משיכה. תכננו ל-polling ותבנו משהו יציב.

מה באמת אפשר לבנות

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

1. קליטת חשבוניות: סוכן AI קורא PDF-ים של ספקים מהמייל או מ-Drive, מחלץ ספק, סכום, מע"מ ותאריך, ויוצר מסמך הוצאה תואם ב-iCount דרך ה-API - כשאדם מאשר כל דבר מתחת לסף ביטחון.
2. עוזר וואטסאפ/מייל מבוסס נתונים אמיתיים: לקוח שואל 'האם התשלום שלי עבר' והבוט שולף את המסמך הרלוונטי מ-iCount במקום להמציא, ועונה מתוך הרשומה האמיתית.
3. התאמות והתראות חריגות: ג'וב לילי מושך מסמכים אחרונים, מודל שפה מסמן כפילויות, סכומים עגולים חשודים, או לקוח שיתרת החוב שלו חצתה סף, ושולח סיכום בעברית ל-Slack.
4. סיכומי סגירת חודש: מושכים את מסמכי התקופה ונותנים למודל לכתוב תקציר הכנסות/מע"מ בשפה פשוטה לבעל העסק ולרואה החשבון.
5. אוטומציה מליד לחשבונית: כשעסקה נסגרת ב-CRM, מייצרים ושולחים חשבונית iCount אוטומטית, ורושמים זאת בחזרה ל-CRM.

No-code (Make/Zapier) מול קוד מותאם

אני לא מקודש לכתיבת קוד במקום שלא צריך. אם הנפח נמוך, הלוגיקה פשוטה וקיים קונקטור, תרחיש ב-Make או Zapier שקורא ישירות ל-API של iCount הוא לרוב התשובה הנכונה והזולה - אפשר לאפיין את זרימת יצירת החשבונית בצהריים אחד.

עוברים לקוד מותאם כשאחד מאלה נכון: הנפח דוחף אתכם מעבר למגבלת הקצב וצריך תור אמיתי והאטה; אתם שולחים מידע פיננסי למודל שפה והטיפול בפרטיות וב-PII חייב להיות הרמטי; הלוגיקה באמת מורכבת (התאמות רב-שלביות, סינון לפי ביטחון, ניתוח טקסט בעברית); או שפשוט אין קונקטור לאותו endpoint מדויק של iCount ואתם חייבים לקרוא לו ישירות. רוב הפרויקטים הרציניים מסתיימים בשירות דק וב-tested היטב שמחזיק את הקריאות ל-iCount ול-AI, כשכלי ה-no-code מצטמצם לטריגר - או נעלם לגמרי.

אם אתם בעלי עסק שקוראים את זה וחושבים 'אני רוצה לחבר את המערכות הקיימות שלי ל-AI אבל לא רוצה למסור את המידע הפיננסי שלי למשהו רעוע' - זו בדיוק העבודה שאני עושה. אני בונה את אינטגרציית ה-iCount מקצה לקצה: טיפול מאובטח בסודות, polling שפוי, שכבת ה-AI שמוסיפה שיקול דעת, ואדם בלולאה בכל מקום שבו מעורב כסף. אם בא לכם לשכור מפתח שיחבר את iCount לסוכני AI ואוטומציות כמו שצריך, צרו קשר דרך טופס יצירת הקשר למטה וספרו לי מה אתם מנסים לאטמט - אגיד לכם בכנות אם זה צהריים של no-code או בנייה אמיתית.