שליחת רישום של מספר טלפון למדריך

שליחת רישום למדריך של מפעיל התקשורת

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

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

דרישות לחשבון ולמספר

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

בקשת POST עם נתוני טופס

הגדירו את NUMBER למספר שבבעלותכם. החליפו את הדוגמה הבדויה בפרטי הרישום שאושרו. נתיב זה קורא שדות טופס מתוך POST; הוא אינו מפענח גוף בקשה מסוג application/json.

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --data-urlencode "lastname=EXAMPLE" \
  --data-urlencode "firstname=EXAMPLE" \
  --data-urlencode "streetnum=1" \
  --data-urlencode "streetname=Example" \
  --data-urlencode "streetpredir=N" \
  --data-urlencode "streetpostdir=W" \
  --data-urlencode "city=Example City" \
  --data-urlencode "state=NY" \
  --data-urlencode "postalcode=10001" \
  "https://api.multitel.net/v3/directory/$NUMBER"

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

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

אופן החיוב והניסיונות החוזרים

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

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

תגובה

{
  "status": {
    "code": 200,
    "msg": "Success"
  },
  "response": ""
}

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

שגיאות במערכת הישנה

בדקו גם את סטטוס HTTP וגם את שדות JSON status.code/status.msg. אימות זהות והגבלות על כתובת IP המקור עשויים גם הם למנוע קבלת תגובה שימושית. אין להשתמש ב-GET או בפרמטרים של שאילתה כדי לבקש עדכון רק משום שלרכיב הטיפול הישן אין מנגנון מפורש להגבלת שיטת HTTP.

בצעו אימות לפני ניסיון חוזר

1. לפני שליחת הבקשה, ודאו את המספר שבבעלותכם, את התאמת מפעיל התקשורת, את נתוני הרישום שאושרו ואת החיוב.
2. שלחו פעם אחת ושמרו את התוצאה בצד החשבון, בלי לחשוף את כתובת הלקוח ביומנים ציבוריים או במערכות ניתוח נתונים.
3. בדקו את הרישום שנשמר ואת היסטוריית העסקאות באמצעות תהליך החשבון הנתמך או דרך התמיכה. המתינו למשך זמן הטיפול שאישר מפעיל התקשורת; API זה אינו מגדיר מועד מובטח להשלמת ההפצה.
4. כאשר התוצאה אינה ודאית, בקשו מהתמיכה לברר ולהתאים את ההזמנה אצל מפעיל התקשורת ואת החיוב המקומי לפני ניסיון נוסף. בקשה חוזרת אינה בדיקת סטטוס אידמפוטנטית.