מפתחים

PUT/tcr/v2/brand/{brandId}/externalVetting

ייבוא תוצאת בדיקה קיימת

שיוך תוצאה קיימת של ספק נתמך למותג שלכם.

בעמוד זה
  1. השתמשו במותג הודעות השייך לחשבון
  2. השתמשו בתוצאה קיימת של ספק
  3. הכינו את הייבוא
  4. ייבאו את התוצאה פעם אחת
  5. הבינו את החיובים הקיימים
  6. עקבו אחר התוצאה בפועל
  7. נסו שוב את אותה בקשה שהתכוונתם לבצע

השתמשו במותג הודעות השייך לחשבון

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

השתמשו בתוצאה קיימת של ספק

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

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

הכינו את הייבוא

שדות לייבוא בדיקה חיצונית
שדהערך
evpIdמזהה ספק נתמך, באורך 1–10 תווים.
vettingIdהמזהה האמיתי של עסקת הבדיקה אצל הספק, באורך של עד 255 תווים. אין להשתמש במזהה המותג במקומו או להמציא מזהה.
vettingTokenאסימון אישור כאשר הספק דורש אותו, באורך של עד 65535 תווים. התייחסו אליו כאל סוד והשמיטו אותו כאשר הספק אינו דורש אותו.

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

ייבאו את התוצאה פעם אחת

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  --request PUT \
  --header 'Content-Type: application/json' \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  --data-binary @vetting-import.json \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID/externalVetting"

הבינו את החיובים הקיימים

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

עקבו אחר התוצאה בפועל

תשובת HTTP מוצלחת עשויה להכיל רשומת בדיקה שעדיין ממתינה להשלמה. שמרו את vettingId שלה ובדקו את vettingStatus, הסיבות, הציון ותאריכי תחילת התוקף ופקיעת התוקף, ככל שהם זמינים. המצבים PENDING ו־UNSCORE דורשים המשך מעקב; המצבים ACTIVE, FAILED ו־EXPIRED מתארים תוצאות שונות. קבלה ברמת HTTP בלבד אינה מוכיחה ציון חיובי או זכאות לקמפיין.

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

נסו שוב את אותה בקשה שהתכוונתם לבצע

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

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