সংশোধিত ব্যবসায়িক পরিচয় আবার যাচাই করুন
বিদ্যমান কোনো প্রতিষ্ঠানের ব্র্যান্ডের সংশোধিত পরিচয়সংক্রান্ত তথ্য আবার যাচাই করতে হলে এই কার্যক্রম ব্যবহার করুন। প্রথমে বিদ্যমান ব্র্যান্ড হালনাগাদ করুন, তারপর পরিচয় যাচাইয়ের বর্তমান অবস্থা দেখুন। প্রোফাইলের সাধারণ হালনাগাদ এই আলাদা ফি প্রযোজ্য যাচাইয়ের অনুরোধ জমা দেয় না। পুনরায় যাচাই করলে আরেকটি ব্র্যান্ড তৈরি হয় না বা কোনো প্রচারাভিযান নিবন্ধিত হয় না।
অনুমোদিত উৎস IP থেকে HTTPS-এর মাধ্যমে আপনার নিজের সক্রিয় API অ্যাকাউন্ট ব্যবহার করুন। ব্র্যান্ডটি অবশ্যই সেই অ্যাকাউন্টের মালিকানাধীন হতে হবে। ব্র্যান্ডের রেকর্ড গোপন রাখুন: এতে ব্যবসা ও যোগাযোগের তথ্য থাকে।
অনুরোধ জমা দেওয়ার আগে ব্র্যান্ড পর্যালোচনা করুন
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 অক্ষর ব্যবহার করা যায়। একই অনুরোধের প্রক্রিয়াকরণ চলাকালে তার অনুলিপি পাঠালে Retry-After সহ 409 ফেরত আসতে পারে; সম্পন্ন অনুরোধের ক্ষেত্রে ত্রুটিসহ তার সংরক্ষিত ফলাফল আবার ফেরত আসতে পারে।
সর্বজনীন API সক্রিয় টোকেন অ্যাকাউন্টের জন্য Bearer প্রমাণীকরণও গ্রহণ করে। অ্যাকাউন্টের মালিকানা এবং অনুমোদিত উৎস IP যাচাই তখনও প্রযোজ্য। সংরক্ষিত পরীক্ষামূলক ব্র্যান্ডের ক্ষেত্রে বাস্তব ব্যবহারের এই ফি প্রক্রিয়া এড়িয়ে যাওয়া হয়, তবে স্যান্ডবক্সের ফলাফল বাস্তব ব্যবহারের পরিচয় যাচাই নয়।
ফলাফল পড়ুন এবং অবস্থার অগ্রগতি দেখুন
| প্রতিক্রিয়া | অর্থ ও পরবর্তী করণীয় |
|---|---|
| 200 | অনুরোধ সফল হয়েছে। ফেরত পাওয়া ব্র্যান্ড পরীক্ষা করুন এবং পরিচয় যাচাইয়ের অবস্থা নিশ্চিত করতে বর্তমান ব্র্যান্ডের রেকর্ড আবার পড়ুন। |
| 202 | গৃহীত হয়েছে, আরও যাচাইয়ের অপেক্ষায় রয়েছে। ব্র্যান্ডের ID সংরক্ষণ করুন এবং আরেকটি ফি প্রযোজ্য অনুরোধ জমা না দিয়ে পরে এর বর্তমান অবস্থা পরীক্ষা করুন। |
| 400 | ফেরত পাওয়া রেজিস্ট্রির ত্রুটিগুলো পর্যালোচনা করুন। মূল নিবন্ধন মুলতবি থাকতে পারে, প্রোফাইল অপরিবর্তিত থাকতে পারে অথবা অন্য কোনো বৈধতা যাচাইয়ের নিয়ম প্রযোজ্য হতে পারে। |
| 401 / 404 | প্রমাণীকরণের তথ্য ও অনুমোদিত IP, অথবা অ্যাকাউন্টের মালিকানাধীন ব্র্যান্ডের ID পরীক্ষা করুন। |
| 402 / 503 | স্থানীয় কেনাকাটা/অর্থায়ন অথবা মূল্য নির্ধারণ/পরিষেবার ত্রুটি পর্যালোচনা করুন। প্রতিটি 503 যে উজানের পরিষেবায় কোনো অনুরোধ পাঠানো হয়নি তার প্রমাণ, এমন ধরে নেবেন না। |
| 429 | Retry-After অনুসরণ করুন এবং একই যাচাইয়ের অনুরোধের বিবরণ অপরিবর্তিত রাখুন। |
কোনো পরিবর্তনের অনুরোধ গৃহীত হলে প্রক্সি তার স্থানীয় ব্র্যান্ডের রেকর্ড হালনাগাদ করে; শুধু এই হালনাগাদ চূড়ান্ত যাচাইয়ের ফলাফলের প্রমাণ নয়। কোনো ব্যবসা অযাচাইকৃত বা মুলতবি অবস্থায় থাকতে পারে। প্রচারাভিযানের সেটআপ এগিয়ে নেওয়ার আগে শুধু HTTP গ্রহণের ওপর নির্ভর না করে ব্র্যান্ডের বর্তমান অবস্থা ব্যবহার করুন।
অনিশ্চিত ফলাফলের ক্ষেত্রে প্রকৃত অবস্থা নির্ণয় করুন
তথ্য পরিবহনে ব্যর্থতার ফলে ক্যাশে সংরক্ষিত 502 পাওয়া যেতে পারে। উজানের পরিষেবায় অনুরোধ গৃহীত হওয়ার পর স্থানীয়ভাবে তথ্য স্থায়ীভাবে সংরক্ষণ বা বিলিং ব্যর্থ হলে requestId সহ ক্যাশে সংরক্ষিত 500 পাওয়া যেতে পারে। ওই শনাক্তকারী সংরক্ষণ করুন এবং সহায়তা বিভাগের সঙ্গে ব্র্যান্ড ও বিলিংয়ের বর্তমান অবস্থা মিলিয়ে নিন। আরেকটি কী তৈরি করলে আলাদাভাবে বিলযোগ্য যাচাইয়ের অনুরোধ তৈরি হতে পারে; না বুঝে নতুন কী দিয়ে পুনঃচেষ্টা করবেন না।
গ্রাহক পোর্টাল ব্যবহার
বর্তমান প্রোফাইল ও ফি পর্যালোচনার পর পোর্টাল বাস্তব ব্যবহারের পরিবেশে UNVERIFIED অবস্থায় থাকা প্রতিষ্ঠানের জন্য পুনরায় যাচাইয়ের সুবিধা দেয়। এটি পরীক্ষা করে যে প্রোফাইল ও মূল্য পরিবর্তিত হয়নি এবং একই বর্তমান বিবরণের জন্য আরেকটি গৃহীত অনুরোধ জমা দেওয়া প্রত্যাখ্যান করে। স্যান্ডবক্স ও একক মালিকানার ব্র্যান্ড এই পোর্টাল কার্যক্রমের অন্তর্ভুক্ত নয়।
পোর্টালের এই সুরক্ষাব্যবস্থাগুলো কার্যপ্রবাহের অতিরিক্ত পরীক্ষা। সরাসরি API ব্যবহারকারী ক্লায়েন্টকে নিজস্ব পর্যালোচনা করতে হবে এবং API-তে পোর্টালের সংস্করণ বা মূল্য নিশ্চিতকরণের ফিল্ড আবশ্যক বলে ধরে নেওয়া যাবে না। ব্র্যান্ডের সাধারণ সংশোধন সংরক্ষণ করা একটি আলাদা কাজ এবং এটি স্বয়ংক্রিয়ভাবে পুনরায় যাচাইয়ের অনুরোধ জমা দেয় না।