רוב העסקים שמחפשים API רשמי למעקב אחרי דואר ישראל מגיעים בסוף לספק צבירה רב-מובילים. למה זו בדרך כלל התשובה הנכונה, מה זה עולה, ואילו החלטות תכנון חשובות יותר מהמקור.
עיקרי הדברים
- לשאול את דואר ישראל ישירות לפני שמניחים. האם קיים API ציבורי מתועד לסוג החשבון שלך היא שאלה אליהם, בכתב - לא משהו להסיק מתוצאות חיפוש.
- ספק צבירה רב-מובילים הוא בדרך כלל התשובה המעשית, כי רוב העסקים שולחים ביותר ממוביל אחד ופורמט מנורמל אחד עדיף על כמה אינטגרציות.
- Webhooks ולא תשאול. סטטוס מעקב משתנה כמה פעמים לאורך ימים - תשאול כל חבילה בתזמון מבזבז קריאות ומעכב את העדכון שללקוח באמת אכפת ממנו.
- למפות סטטוסים של המוביל לסט קטן משלך. הניסוח הגולמי משתנה ושונה בין מובילים; ללקוחות צריך שלושה-ארבעה מצבים, לא את אוצר המילים של המוביל.
הצורך פשוט: לקוח הזמין, נשלחה חבילה, ורוצים שהמערכת תדע מתי היא נמסרה - בלי שמישהו יכניס מספר מעקב לאתר ידנית. מי שמחפש "API של דואר ישראל" מגלה מהר שהתשובה פחות ישירה ממה שציפה, ורוב העסקים מגיעים בסוף לאותו מקום.
קודם: לשאול, לא להסיק
אני לא מפרסם כאן endpoint. האם קיים ממשק ציבורי מתועד, ולאיזה סוג חשבון או הסכם הוא זמין, היא שאלה שיש להפנות ישירות לדואר ישראל - בכתב, לפני שמתמחרים.
הסיבה שאני מתעקש על זה: זהו בדיוק המקרה שבו מאמר בן שנתיים ששלף endpoint שולח מפתח לרדוף אחרי משהו שהשתנה או שמעולם לא היה זמין לחשבון שלו. אותו כלל שאני מחיל על iCount ועל חשבשבת.
שתי שאלות ספציפיות ששוות לשאול:
- האם יש ממשק תכנותי למעקב, ומה נדרש כדי לקבל גישה?
- האם הוא זמין ללקוח עסקי רגיל, או רק במסגרת הסכם מסחרי?
מה שרוב העסקים עושים בפועל
המסלול הנפוץ הוא ספק צבירה רב-מובילים - שירות צד שלישי שמנרמל מעקב אחרי מאות מובילים לפורמט אחד, כולל דואר ישראל.
וזה לא פשרה. זו לרוב הבחירה הנכונה, ומסיבה עסקית ולא טכנית:
| ישירות מול מוביל | ספק צבירה |
|---|---|
| אינטגרציה נפרדת לכל מוביל | פורמט אחד לכולם |
| שינוי אצל המוביל שובר אותך | הספק סופג את השינוי |
| חינם, אם קיים | עלות שוטפת |
| תלוי בזמינות ובהסכם | נגיש מיד |
הנקודה המכריעה: רוב העסקים לא שולחים רק בדואר ישראל. יש שליח לעיר, דואר לפריפריה, ואולי מוביל בינלאומי. אם אתה בונה שלוש אינטגרציות נפרדות עם שלושה מודלים שונים של סטטוס - בנית שלוש מערכות לתחזק. ספק צבירה הופך את זה לאחת.
מה שכן צריך לבדוק לפני שבוחרים ספק:
- האם דואר ישראל מכוסה ובאיזו רמת פירוט.
- האם יש webhooks או רק תשאול. זה משנה יותר ממה שנדמה - ראה למטה.
- מה קורה כשמוביל לא מחזיר עדכון. ספק שמציג "אין מידע" ככשל הוא רעש; ספק שמבחין בין "אין עדיין" ל"נכשל" שימושי.
ההחלטה שקובעת יותר מהמקור: webhooks או תשאול
וזו הנקודה שהכי משפיעה על העלות ועל החוויה.
מעקב משלוחים הוא אירוע נדיר. חבילה משנה סטטוס אולי שלוש-ארבע פעמים לאורך כמה ימים. תשאול כל החבילות הפתוחות כל שעה משמעו מאות קריאות שרובן מחזירות "אין שינוי".
| תשאול | Webhook | |
|---|---|---|
| קריאות | הרבה, רובן מיותרות | אחת לכל שינוי |
| עדכניות | עד מחזור התשאול | מיידית |
| מורכבות | נמוכה | צריך נקודת קצה ציבורית |
אם יש webhooks - להשתמש בהם. וכמו בכל webhook: לאמת שההודעה באמת מהספק, להחזיר תשובה מיד, ולהיות אידמפוטנטי - אותו עדכון יכול להגיע פעמיים ואסור שזה ישלח שתי הודעות ללקוח.
ואם רק תשאול: לתשאל רק חבילות פתוחות. חבילה שנמסרה לא צריכה בדיקה נוספת, וחבילה שלא זזה שבועיים כנראה לא תזוז - כדאי להוציא אותה מהמחזור ולסמן לבדיקה אנושית.
מיפוי סטטוסים - הדבר שכולם מדלגים עליו
מובילים מחזירים ניסוחים משלהם, בעברית ובאנגלית, והם משתנים. אל תציג ללקוח את מה שהמוביל אמר.
הסיבה מעשית: כשתוסיף מוביל שני, יהיו לך שני אוצרות מילים על אותו מסך. וכשמוביל ישנה ניסוח, הממשק שלך ישתנה בלי שנגעת בו.
מה שעובד: סט קטן משלך - למשל נשלח, בדרך, ממתין לאיסוף, נמסר, בעיה - ושכבת תרגום מהמוביל אליו. הלקוח רואה מצב אחד ועקבי.
ולשמור את הסטטוס הגולמי בצד. כשמשהו ייראה מוזר, זו הראיה מה המוביל באמת אמר.
מה שנשבר בפועל
- "אין מידע" אינו כשל. חבילה שנמסרה לסניף לפני שעה עדיין לא במערכת. להבחין בין "אין עדיין" ל"שגיאה", אחרת תתריע על כלום.
- מספר מעקב שגוי. הוקלד ידנית, או שהמשלוח בוטל. אחרי כמה ניסיונות - להוציא מהמחזור ולסמן, לא לנסות לנצח.
- מסירה שלא מדווחת. קורה. תהליך שמסמן הזמנות שתקועות מעל X ימים שווה יותר מניסיון לתקן את המעקב.
- עברית בהודעה ללקוח. סטטוס עברי עם מספר מעקב באותה שורה הוא טקסט מעורב, ובהודעת SMS או וואטסאפ אין CSS שיסדר אותו.
מה זה שווה ללקוח
נקודה שכדאי לומר ללקוח לפני שבונים: מעקב אוטומטי לא מזרז משלוחים. מה שהוא נותן:
- פחות פניות "איפה ההזמנה". זו החיסכון האמיתי, ואפשר לכמת אותו - כמה פניות כאלה בחודש.
- גילוי מוקדם של חבילה תקועה, לפני שהלקוח מתלונן.
- סגירת ההזמנה אוטומטית במערכת כשנמסרה.
ואם המספר הוא חמש פניות בחודש - שווה להגיד שזה לא מצדיק פרויקט. עדכון ידני של חבילות פתוחות פעם ביום עולה פחות מאינטגרציה שצריך לתחזק.
צ'קליסט
- לשאול את דואר ישראל בכתב מה קיים ולמי - לפני התמחור.
- אם שולחים ביותר ממוביל אחד - ספק צבירה כמעט תמיד עדיף.
- לבדוק אם יש webhooks; אם כן, להשתמש בהם.
- לתשאל רק חבילות פתוחות, ולהוציא תקועות מהמחזור.
- למפות לסט סטטוסים משלך ולשמור את הגולמי.
- אידמפוטנטיות - עדכון כפול לא שולח שתי הודעות.
- לכמת כמה פניות "איפה ההזמנה" יש בחודש לפני שבונים.
שאלות נפוצות
האם לדואר ישראל יש API ציבורי למעקב?
האם קיים ממשק ציבורי מתועד, ולאיזה סוג חשבון או הסכם מסחרי, היא שאלה שיש להפנות ישירות לדואר ישראל בכתב לפני שמתמחרים עבודה. פרסום endpoint ממאמר הוא בדיוק הדרך שבה מפתחים רודפים אחרי משהו שהשתנה או שמעולם לא היה זמין לחשבון שלהם. בפועל רוב העסקים משתמשים בספק צבירה רב-מובילים.
למה להשתמש בספק צבירה במקום ישירות מול המוביל?
כי רוב העסקים לא שולחים רק במוביל אחד - יש שליח לעיר, דואר לפריפריה, לפעמים מוביל בינלאומי. שלוש אינטגרציות ישירות משמען שלושה מודלי סטטוס שונים ושלוש מערכות לתחזק, בעוד שספק צבירה מנרמל אותן לפורמט אחד וסופג שינויים אצל המובילים במקומך.
האם מעקב משלוחים צריך להשתמש בתשאול או ב-webhooks?
Webhooks כשהם זמינים. חבילה משנה סטטוס רק שלוש-ארבע פעמים לאורך כמה ימים, ולכן תשאול כל חבילה פתוחה בכל שעה מייצר מאות קריאות שרובן מחזירות חוסר שינוי, ובמקביל מעכב את העדכון שללקוח אכפת ממנו. אם רק תשאול זמין, לתשאל רק חבילות פתוחות ולהוציא כאלה שלא זזו שבועות.
האם לקוחות צריכים לראות את ניסוח הסטטוס של המוביל?
לא. יש למפות סטטוסים של מובילים לסט קטן משלך - נשלח, בדרך, ממתין לאיסוף, נמסר, בעיה - ולשמור את הערך הגולמי בצד לצורכי ניפוי. אחרת הוספת מוביל שני מכניסה שני אוצרות מילים לאותו מסך, ומוביל שמשנה ניסוח משנה את הממשק שלך בלי שנגעת בכלום.
האם שווה לבנות מעקב משלוחים אוטומטי?
זה תלוי בכמה פניות "איפה ההזמנה" מגיעות בחודש - זה החיסכון שניתן לכימות, לצד גילוי מוקדם של חבילות תקועות וסגירת הזמנה אוטומטית. מעקב אוטומטי לא מזרז משלוחים. בחמש פניות בחודש זה לא מצדיק פרויקט; עדכון ידני של חבילות פתוחות פעם ביום עולה פחות מאינטגרציה שצריך לתחזק.
להמשך קריאה
שירות רלוונטי
אינטגרציות
לגרום למערכות שאתם כבר משלמים עליהן לדבר זו עם זו.
על הכותב
יהונתן סעדיה
מהנדס פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מהנדס בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה מנסה להפוך לאוטומטי או לבנות, ואומר לך מהי הדרך המהירה והאמינה ביותר ליישם את זה.