קריאת אירועים בפרויקט ניוד

גישה לחשבון ולפרויקט

יש להשתמש בחשבון API פעיל דרך HTTPS מכתובת IP מורשית. הפרויקט חייב להשתייך לאותו חשבון ואסור שיהיה מחוק. יש להשתמש במזהה הייחודי של הפרויקט מתהליך הזמנת הניוד, ולא במזהה המספרי שלו במסד הנתונים או במספר טלפון. בעת בניית בקשה, יש לקודד את מזהה הפרויקט בקידוד כתובות URL.

בקשה

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/v3/lnp/project/$PROJECT_ID/events"

תגובה

דוגמה לתגובה עם נתונים בדויים.

{
  "status": {
    "code": 200,
    "msg": "Project Events",
    "results": 1
  },
  "response": [
    {
      "id": 31,
      "subject": "Example project update",
      "event": "{\"type\":\"comment\",\"value\":\"Example update\",\"source\":\"Example source\"}",
      "type": "comment",
      "value": "Example update",
      "source": "Example source",
      "date_created": "2026-10-23 12:00:00"
    }
  ]
}

עבור פרויקט קיים ללא אירועים מוחזרים קוד API בערך 200, רשימה ריקה וערך status.results השווה ל-0. התוצאות מתבקשות בסדר יורד לפי זמן היצירה, ללא מיון נוסף כאשר זמני היצירה זהים, ללא חלוקה לעמודים, ללא סמן וללא מסנן תאריכים.

יש לקרוא בעיון את מטען הנתונים של האירוע

id הוא המזהה המספרי של שורת האירוע, subject הוא הנושא השמור שלו, ו-date_created הוא ערך התאריך והשעה השמור שלו. נקודת הקצה שומרת ללא שינוי את המחרוזת הגולמית event וגם מנסה לפענח מתוכה את type, value ואת source. אם מטען הנתונים אינו אובייקט JSON או שמאפיין חסר, השדה המפוענח המתאים הוא מחרוזת ריקה.

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

ההיסטוריה אינה מבטיחה מסירה

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

שגיאות ומגבלות

יש לבדוק גם את תגובת HTTP וגם את status.code/status.msg. עבור פרויקט שאינו קיים, שנמחק או שאינו שייך לחשבון מוחזר קוד API בערך 404 עם הודעה שהפרויקט לא נמצא. חלות גם דרישות אימות ומגבלות על כתובת ה-IP שממנה נשלחת הבקשה. הדוגמאות אינן שולחות בקשה בפועל, ותגובה מוצלחת אינה הוכחה שמפעיל תקשורת קיבל את הניוד או השלים אותו.

השפעות

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