আপনার অ্যাকাউন্টে থাকা একটি ব্র্যান্ড নির্বাচন করুন
আপনার MultiTEL অ্যাকাউন্টের সঙ্গে আগে থেকেই যুক্ত থাকা রেজিস্ট্রির ব্র্যান্ড আইডি দিয়ে শুরু করুন। এই অনুসন্ধান কোনো ব্র্যান্ড তৈরি করে না বা অন্য কারও ব্র্যান্ড আপনার অ্যাকাউন্টে যুক্ত করে না। বর্তমান গ্রাহক কার্যপ্রবাহে যোগ্যতার তথ্য চাওয়ার আগে মালিকানা যাচাই করা হয়। অনুসন্ধানে 404 ফেরত এলে স্থানীয় সারির আইডি বসিয়ে দেওয়ার পরিবর্তে নির্বাচিত অ্যাকাউন্ট ও ব্র্যান্ড যাচাই করুন।
এই ফলাফল থেকে ব্যবহারের ধরনের বিকল্পগুলো তৈরি করুন
ব্যবহারের ধরনের সাধারণ তালিকায় রেজিস্ট্রির বিকল্পগুলোর বিবরণ থাকে। ব্র্যান্ডভিত্তিক এই অনুসন্ধান নির্বাচিত ব্র্যান্ডের বিকল্পগুলো দেয়। ফেরত আসা প্রতিটি usecase মান অক্ষুণ্ণ রাখুন এবং তালিকায় থাকা তার প্রদর্শনযোগ্য নাম ও বিবরণের সঙ্গে যুক্ত করুন। সাধারণ তালিকার প্রতিটি বিকল্প এমনভাবে দেখাবেন না যেন ব্র্যান্ডটি তার সবগুলোর জন্য যোগ্য।
পোর্টাল এই প্রতিক্রিয়াটি একটি JSON তালিকা হবে বলে প্রত্যাশা করে। এটি অনুপস্থিত বা ভুল গঠনের হলে কিংবা ত্রুটি হলে গ্রাহকের ফর্ম অক্ষুণ্ণ রাখুন এবং জানান যে যোগ্যতার তথ্য লোড করা যায়নি। কিছু না জানিয়ে এটিকে পূর্বনির্ধারিত কোনো ব্যবহারের ধরনের অনুমোদন হিসেবে ধরবেন না। সংক্ষিপ্ত উদাহরণে দেখানো ফিল্ডগুলোর বাইরেও রেজিস্ট্রি অতিরিক্ত ফিল্ড ফেরত দিতে পারে।
নির্বাচিত ব্যবহারের ধরনের শর্তগুলো লোড করুন
গ্রাহক ফেরত আসা ব্যবহারের ধরনের একটি মান বেছে নেওয়ার পর অনুরোধ করুন /tcr/v2/campaignBuilder/brand/{brand_id}/usecase/{usecase} একই ব্র্যান্ডের জন্য। সেই প্রতিক্রিয়ায় উপ-ব্যবহারের ধরনের সীমা এবং অপারেটরভিত্তিক শর্তগুলো পাওয়া যায়। বার্তার নমুনা, সম্মতি ও অন্যান্য আবশ্যক ঘোষণা সংগ্রহ করতে এটি ব্যবহার করুন। সম্পূর্ণ ক্যাম্পেইন নিবন্ধন প্রস্তুত করার জন্য শুধু যোগ্যতার তালিকা যথেষ্ট নয়।
অ্যাকাউন্টের মূল্যতালিকা আলাদাভাবে পর্যালোচনা করুন
প্রদানকারীর ফিল্ডগুলো, যেমন monthlyFee, quarterlyFee অথবা annualFee, ফেরত এলে প্রদানকারীর ফি-সংক্রান্ত মেটাডেটা বর্ণনা করে। এগুলো গ্রাহকের অ্যাকাউন্টের মূল্য বা নিবন্ধনের শর্তের বিকল্প নয়। বর্তমান পোর্টাল ক্যাম্পেইনের খুচরা মূল্য আলাদাভাবে পড়ে এবং পর্যালোচনা পর্দায় দেখানোর জন্য তা যোগ্যতার তথ্যের সঙ্গে যুক্ত করে। পুরোনো এনাম সহায়ক কোডে স্থিরভাবে বসানো মূল্য থেকে গ্রাহকের প্রদেয় অর্থ অনুমান করবেন না।
ব্র্যান্ড বা ব্যবহারের ধরন বদলালে তথ্য হালনাগাদ করুন
ব্র্যান্ড বদলানোর সময় আগের ব্র্যান্ডের বিকল্পগুলো বাদ দিন এবং নতুন নির্বাচিত ব্র্যান্ডের যোগ্যতার তথ্য লোড করুন। জমা দেওয়ার আগে নির্বাচিত ব্যবহারের ধরনের শর্তগুলো নতুন করে লোড করুন। এই GET অনুরোধগুলো কোনো নিবন্ধন জমা দেয় না, ক্যাম্পেইন সক্রিয় করে না বা নম্বর বরাদ্দ করে না।
অনুরোধ
অনুমোদিত উৎস আইপি ঠিকানা থেকে HTTPS-এর মাধ্যমে একটি সক্রিয় API অ্যাকাউন্ট ব্যবহার করুন। বর্তমান রুট অ্যাকাউন্টের প্রমাণীকরণ নীতি সমর্থন করে, যার মধ্যে Basic প্রমাণীকরণ ও সক্রিয় বেয়ারার API অ্যাকাউন্ট অন্তর্ভুক্ত। প্রদানকারীর প্রমাণীকরণের তথ্য ব্যবহার করবেন না।
ইউআরএল পাথে ব্র্যান্ডের শনাক্তকারী দিয়ে GET অনুরোধ করুন। অনুরোধের কোনো বডি প্রয়োজন নেই।
curl --fail-with-body --silent --show-error \
--user "$API_USER:$API_PASSWORD" \
"https://api.multitel.net/tcr/v2/campaignBuilder/brand/$BRAND_ID"| নাম | ধরন | আবশ্যক | বিবরণ |
|---|---|---|---|
brand_id | স্ট্রিং | হ্যাঁ | আপনার প্রমাণীকৃত MultiTEL অ্যাকাউন্টের সঙ্গে যুক্ত রেজিস্ট্রির ব্র্যান্ড আইডি। ব্র্যান্ড আইডি ব্যবহার করুন, স্থানীয় ডেটাবেসের সারির আইডি, ক্যাম্পেইন আইডি বা ব্যবসার কর নম্বর নয়। এটিকে ইউআরএল পাথের একটি একক সেগমেন্ট হিসেবে এনকোড করুন। |
প্রতিক্রিয়া
বর্তমান TCR রুট রেজিস্ট্রির JSON বডি সরাসরি ফেরত দেয় এবং এর HTTP স্ট্যাটাস অক্ষুণ্ণ রাখে। এটি পুরোনো v3 সংস্করণের status/response মোড়ক যোগ করে না। সংক্ষিপ্ত কাল্পনিক উদাহরণটি কোনো সরাসরি প্রাপ্ত যোগ্যতার ফলাফল নয়। এটি ব্যবহারের আগে HTTP স্ট্যাটাস ও প্রত্যাশিত JSON গঠন যাচাই করুন। বর্তমান পোর্টাল যোগ্যতার রেকর্ডের একটি তালিকা প্রত্যাশা করে, যার প্রতিটি একটি usecase শনাক্ত করে। প্রদর্শনযোগ্য নামের জন্য এটি সেই রেকর্ডগুলোকে usecase তালিকার সঙ্গে যুক্ত করে এবং খুচরা মূল্য আলাদাভাবে পড়ে। প্রদানকারীর অতিরিক্ত ফিল্ডও থাকতে পারে।
প্রতিক্রিয়ার গঠনের উদাহরণ; এটি অ্যাকাউন্টের সরাসরি প্রাপ্ত তথ্য বা বর্তমান মূল্যপ্রস্তাব নয়।
[
{
"usecase": "2FA"
}
]ত্রুটি
- 401: অ্যাকাউন্টের প্রমাণীকরণ ব্যর্থ হয়েছে। API প্রমাণীকরণের তথ্য, অ্যাকাউন্ট সক্রিয় আছে কি না এবং প্রযোজ্য উৎস আইপি বিধিনিষেধ যাচাই করুন।
- 404: ব্র্যান্ডটি প্রমাণীকৃত অ্যাকাউন্টের সঙ্গে যুক্ত নয়, অথবা প্রদানকারী অনুরোধ করা ব্র্যান্ড বা নির্বাচিত বিকল্পটি খুঁজে পাচ্ছে না। প্রদানকারীর কাছে অনুরোধ পাঠানোর আগেই স্থানীয় মালিকানা যাচাইয়ে প্রত্যাখ্যানের প্রতিক্রিয়া ফেরত দেওয়া হয়।
- রেজিস্ট্রির অন্যান্য ত্রুটি: উজানের সেবার HTTP স্ট্যাটাস ও বডি অক্ষুণ্ণ রাখা হয়। অবৈধ বা অনুপলব্ধ ব্যবহারের ধরনকে সফল প্রতিক্রিয়ায় শর্তের খালি সমষ্টি পাওয়া হিসেবে ধরা যাবে না।
- 429: অ্যাকাউন্টের বা প্রদানকারীর যৌথ অনুরোধসীমা পূর্ণ হয়েছে। Retry-After নির্দেশনা মেনে চলুন।
- 502/503: পরিবহন ব্যবস্থা, প্রদানকারী বা অনুরোধের হার নিয়ন্ত্রকের প্রাপ্যতায় ব্যর্থতা ঘটেছে। ফর্ম অক্ষুণ্ণ রাখুন এবং অপেক্ষার ব্যবধান বাড়িয়ে আবার চেষ্টা করুন।
প্রাপ্যতা ও পার্শ্বপ্রভাব
- পর্যালোচিত GET অনুরোধ বিদ্যমান ব্র্যান্ডের মালিকানা যাচাই করে, রেজিস্ট্রির সঙ্গে যোগাযোগ করে এবং অনুরোধের নিরীক্ষা রেকর্ড লেখে। এটি কোনো ব্র্যান্ড বা ক্যাম্পেইন তৈরি করে না বা নিবন্ধন ফি ধার্য করে না।
- প্রদানকারীর ফি-সংক্রান্ত মেটাডেটা MultiTEL গ্রাহকের জন্য খুচরা মূল্যপ্রস্তাব নয়। পরবর্তী নিবন্ধন অনুরোধের আগে পোর্টাল অ্যাকাউন্টের মূল্যতালিকা আলাদাভাবে পর্যালোচনা করে।
- যোগ্যতা ও শর্ত বদলাতে পারে। জমা দেওয়ার আগে নির্বাচিত ব্র্যান্ড ও ব্যবহারের ধরনের জন্য সেগুলো নতুন করে লোড করুন। সফল অনুসন্ধান মানে ক্যাম্পেইনের অনুমোদন, নম্বর বরাদ্দ বা বার্তা পাঠানো শুরু করার অনুমতি নয়।