অ্যাকাউন্টের মালিকানাধীন মেসেজিং ব্র্যান্ড ব্যবহার করুন
অনুমোদিত উৎস আইপি থেকে HTTPS-এর মাধ্যমে একটি সক্রিয় API অ্যাকাউন্ট ব্যবহার করুন। 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 অক্ষর ব্যবহার করা যায়। চলমান অনুরোধের অনুলিপি পাঠালে Retry-After-সহ 409 ফেরত আসতে পারে। সম্পন্ন অনুরোধে ত্রুটিসহ সংরক্ষিত প্রতিক্রিয়াই আবার ফেরত দেওয়া হয়। অনুরোধের হারের সীমা মেনে চলুন।
ডেটা পরিবহনে ব্যর্থতার পর ক্যাশে সংরক্ষিত 502 ফেরত আসতে পারে। requestId-সহ ক্যাশে সংরক্ষিত 500 বোঝাতে পারে যে রেজিস্ট্রি কার্যক্রমটি গ্রহণ করেছে, কিন্তু স্থানীয়ভাবে স্থায়ী সংরক্ষণ বা বিলিং ব্যর্থ হয়েছে। নতুন কী ব্যবহার করার আগে অনুরোধের আইডি সংরক্ষণ করুন, বর্তমান রেকর্ডগুলো পরীক্ষা করুন এবং সহায়তা দলের সঙ্গে মিলিয়ে অসংগতি মিটিয়ে নিন। ত্রুটি দেখা গেছে বলেই কোনো অর্ডার নেই ধরে নেবেন না।