אימות חוזר של מותג להעברת הודעות

בדיקה חוזרת של זהות העסק לאחר תיקונה

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

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

בדקו את המותג לפני ההגשה

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID" \
  --output current-brand.json

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

אשרו את החיוב הנפרד

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

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

הגישו ניסיון יחיד ומכוון

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  --request PUT \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID/revet"

אין צורך בגוף בקשה המכיל פרופיל: הבדיקה מתבצעת על פרטי המותג שכבר נשמרו. השתמשו במפתח אידמפוטנטיות ייחודי לניסיון המתוכנן, ובשליחות חוזרות שמרו על אותה שיטה, אותו נתיב, אותה שאילתה ואותו גוף בקשה בדיוק, ללא שינוי. מפתחות תומכים ב-1–128 תווי ASCII הניתנים להדפסה, ללא רווחים. בקשה כפולה שנמצאת בעיבוד עשויה להחזיר 409 עם Retry-After; ניסיון שהושלם עשוי להחזיר שוב את התוצאה השמורה שלו, לרבות שגיאה.

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

בדקו את התוצאה ועקבו אחר המצב

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

בירור תוצאה שאינה ודאית

כשל בתעבורה עשוי להפיק תשובה 502 שנשמרת במטמון. בקשה שהתקבלה בשירות במעלה השרשרת ולאחריה אירע כשל בשמירה המקומית או בחיוב עשויה להפיק תשובה 500 שנשמרת במטמון עם requestId. שמרו את המזהה הזה ובררו עם התמיכה את מצב המותג והחיוב העדכני כדי ליישב אי-התאמות. יצירת מפתח נוסף עלולה ליצור ניסיון המחויב בנפרד; אל תנסו שוב עם מפתח חדש בלי לברר את המצב.

שימוש בפורטל הלקוחות

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

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