שליחת פרופיל רישום למספר

הכנת הפרופיל השמור והמספר

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

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

1. צרו פרופיל רישום או בחרו פרופיל קיים. שמרו את uuid של הפרופיל המקומי שהתקבל מ־create_document; הפונקציה get_document מחזירה את אותה הפניה מקומית בתור id.
2. להגשה באמצעות מפעיל תקשורת, בפרופיל נדרשות הפניות שמורות לזהות ולכתובת. צרפו את האסמכתאות ואת המסמכים התומכים הנדרשים באמצעות התהליכים המתאימים להם לפני ההגשה.
3. בדקו שהמספר והפרופיל עומדים בדרישות החלות על המדינה ועל המספר. אין להניח שפרופיל שמור מאושר לכל מספר.

שליחת השיוך

curl --silent --show-error --request POST \
  --user "$API_USER:$API_PASSWORD" \
  --form-string document_uuid="$PROFILE_UUID" \
  --form-string service_description="Example customer support line" \
  https://api.multitel.net/v3/number_identity/12125550123

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

בבקשות מרובות חלקים, מערך משתמש בשדות onetime_files[] חוזרים. מתקבלת גם בקשת JSON עם Content-Type: application/json; המאפיינים שלה ממוזגים במטען הנתונים של הטופס. אפשר לספק number במטען הנתונים כאשר המספר אינו כלול בנתיב. העדיפו את הנתיב המפורש המוצג לעיל כדי למנוע עמימות.

הבחנה בין שיוך לאישור

קראו הן את תוצאת ה־HTTP והן את status.code ב־JSON. שגיאות JSON עשויות להגיע עם HTTP 200. הצלחה במסלול המטופל באמצעות מפעיל תקשורת מדווחת על Address verification task created; awaiting carrier review. בדוגמה זו נעשה שימוש בהפניות בדויות.

{
  "status": {
    "code": 200,
    "msg": "Address verification task created; awaiting carrier review."
  },
  "response": {
    "number": "+12125550123",
    "did_id": "11111111111111111111111111111111",
    "document_uuid": "0123456789abcdef0123456789abcdef",
    "identity_id": "22222222222222222222222222222222",
    "address_id": "33333333333333333333333333333333",
    "address_verification_id": "44444444444444444444444444444444",
    "verification_status": "pending",
    "verification_reference": null,
    "requirement_id": "55555555555555555555555555555555",
    "registration_details_id": "8516ac99dc60603295de7bdb6a153530"
  }
}

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

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

טיפול בשגיאות בלי ליצור משימות כפולות

קוד API 400 מציין מספר חסר או הפניה חסרה לפרופיל. קוד 404 מציין פרופיל או מספר שאינם זמינים לחשבון, או מספר שחסר במלאי של מפעיל התקשורת. קוד 422 עשוי לדווח על הפניות חסרות לזהות או לכתובת, על דרישות המוכר או על דחייה בבדיקת התקינות של מפעיל התקשורת. היעדר הגדרת קריאה חוזרת עשוי להפיק 503, וכשל בתקשורת בעת היצירה עשוי להפיק 502. קראו את ההודעה ואת כל נתוני requirement_diagnostics שנכללו, במקום לטפל בכל הכשלים באותו אופן.

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

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

מגבלה על מסמכים חד־פעמיים

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

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

הגנה על פרטי הרישום

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