ডেভেলপার

POST/v3/directory/{number}

ফোন নম্বরের ডিরেক্টরি তালিকাভুক্তি জমা দিন

অনুমোদিত তথ্য দিয়ে অপারেটরের ডিরেক্টরিতে তালিকাভুক্তির অনুরোধ জমা দিন, বর্তমানে কার্যকর চার্জ বুঝে নিন এবং আবার চেষ্টা করার আগে অনিশ্চিত ফলাফল মিলিয়ে নিন।

এই পৃষ্ঠায়
  1. অপারেটরের ডিরেক্টরিতে তালিকাভুক্তির অনুরোধ জমা দিন
  2. অ্যাকাউন্ট ও নম্বরের প্রয়োজনীয় শর্ত
  3. ফর্মের POST অনুরোধ
  4. চার্জ ও পুনরায় চেষ্টার আচরণ
  5. সাড়া
  6. পুরোনো ব্যবস্থার ত্রুটি
  7. আবার চেষ্টা করার আগে যাচাই করুন

অপারেটরের ডিরেক্টরিতে তালিকাভুক্তির অনুরোধ জমা দিন

MultiTEL-এ আপনার মালিকানাধীন উপযুক্ত ফোন নম্বরটি ডিরেক্টরিতে তালিকাভুক্ত করতে যে নাম ও ঠিকানা ব্যবহার করবেন, তা জমা দিন। এটি অপারেটরের কাছে পাঠানো একটি সশুল্ক হালনাগাদ; এটি কলকারীর নাম খোঁজা, ব্যক্তিগত ঠিকানার বইয়ে তথ্য যোগ করা বা পোর্টালের LIDB ইনভেন্টরি ফিল্ডে সাধারণ হালনাগাদ নয়।

ডিরেক্টরিতে তালিকাভুক্তির জন্য গ্রাহক যে তথ্য ব্যবহারের অনুমতি দিয়েছেন, কেবল তা-ই জমা দিন। এই পুরোনো রুট ব্যবহারের আগে নম্বরটির জন্য অপারেটরের সমর্থন নিশ্চিত করুন। পর্যালোচিত হ্যান্ডলার সেবাদাতার উপযুক্ততা বা আন্তর্জাতিক নম্বরের বিন্যাস যাচাই করে না; অপারেটরের কাছে অনুরোধ পাঠানোর সময় এটি নম্বরটিকে উত্তর আমেরিকার নম্বর ধরে নেয় এবং সংরক্ষিত প্রথম অঙ্কটি বাদ দেয়।

অ্যাকাউন্ট ও নম্বরের প্রয়োজনীয় শর্ত

অনুমোদিত উৎস IP ঠিকানা থেকে HTTPS-এর মাধ্যমে সক্রিয় API অ্যাকাউন্ট ব্যবহার করুন। হুবহু সেই নম্বরটি ওই অ্যাকাউন্টের কেনা নম্বরের তালিকায় বাতিল করা হয়নি এমন একটি রেকর্ডে থাকতে হবে। আপনার ইনভেন্টরিতে থাকা সম্পূর্ণ আন্তর্জাতিক নম্বরের অঙ্কগুলো ব্যবহার করুন, যেমন সমর্থিত উত্তর আমেরিকার নম্বরের জন্য দেশ-কোড-1 যুক্ত বিন্যাস। মূল্য পরিকল্পনার আইডি, নম্বরের UUID বা অন্য অ্যাকাউন্টের নম্বর ব্যবহার করবেন না।

ফর্মের POST অনুরোধ

মান নির্ধারণ করুন: NUMBER-এ আপনার মালিকানাধীন নম্বরটি দিন। কাল্পনিক উদাহরণের পরিবর্তে তালিকাভুক্তির অনুমোদিত তথ্য ব্যবহার করুন। এই রুট POST থেকে ফর্মের ফিল্ড পড়ে; এটি application/json বডি পার্স করে না।

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --data-urlencode "lastname=EXAMPLE" \
  --data-urlencode "firstname=EXAMPLE" \
  --data-urlencode "streetnum=1" \
  --data-urlencode "streetname=Example" \
  --data-urlencode "streetpredir=N" \
  --data-urlencode "streetpostdir=W" \
  --data-urlencode "city=Example City" \
  --data-urlencode "state=NY" \
  --data-urlencode "postalcode=10001" \
  "https://api.multitel.net/v3/directory/$NUMBER"
ডিরেক্টরিতে তালিকাভুক্তির ফর্মের ফিল্ড
ফিল্ডএই API-এর জন্য আবশ্যকঅর্থ
lastnameহ্যাঁতালিকাভুক্তির পদবি বা তালিকাভুক্তির নামের প্রযোজ্য ফিল্ড।
cityহ্যাঁতালিকাভুক্তির শহর।
postalcodeহ্যাঁতালিকাভুক্তির ডাকসংকেত।
stateহ্যাঁতালিকাভুক্তির রাজ্য বা অঞ্চল, যা সমর্থিত অপারেটর গ্রহণ করে।
streetnameহ্যাঁরাস্তার নাম।
streetnumহ্যাঁরাস্তার ঠিকানার নম্বর।
firstnameনানামের প্রথম অংশের অতিরিক্ত উপাদান।
streetpredir, streetpostdirনাপ্রযোজ্য ক্ষেত্রে রাস্তার নামের আগে ও পরে থাকা দিকনির্দেশক অংশ।
streettype, locationনাপ্রযোজ্য ক্ষেত্রে রাস্তার ধরন বা অবস্থান সম্পর্কিত অতিরিক্ত লেখা।

উদাহরণের দিকনির্দেশ ও ঠিকানা কেবল নমুনা হিসেবে দেওয়া, এগুলো সুপারিশকৃত ডাকঠিকানা নয়। গ্রাহকের প্রকৃত তথ্যে কাল্পনিক দিকনির্দেশ যোগ করবেন না। API-এর আবশ্যক ফিল্ডের যাচাই সীমিত: এই যাচাই ঠিকানাটি বৈধ বা অপারেটরের কাছে গ্রহণযোগ্য কি না তা নিশ্চিত করে না, এবং পুরোনো ওয়েবসাইটে ফর্মের জন্য ভিন্ন শর্ত প্রযোজ্য ছিল।

ঐচ্ছিক কোনো দিকনির্দেশক অংশ অনুপস্থিত বা খালি থাকলে বর্তমান বাস্তবায়ন অ্যারের কী অনুপস্থিত থাকার সতর্কতা দিতে পারে। সাড়ার গঠন ভুল হলে বা অপারেটর ঠিকানা প্রত্যাখ্যান করলে, অনুরোধের রেফারেন্স সংরক্ষণ করুন এবং ঠিকানা অনুমান করে বারবার পরিবর্তিত তথ্য জমা দেওয়ার পরিবর্তে সহায়তা বিভাগকে তালিকাভুক্তি নিশ্চিত করতে বলুন।

চার্জ ও পুনরায় চেষ্টার আচরণ

পর্যালোচিত হ্যান্ডলার ন্যূনতম ব্যালেন্স হিসেবে পরীক্ষা করে: 10.00 ব্যালেন্স একক অপারেটরের সঙ্গে যোগাযোগ করার আগে। অপারেটর সফলতার কথা জানালে এবং স্থানীয় নম্বরের হালনাগাদ সফল হয়েছে বলে জানানো হলে, এটি 10.00 অ্যাকাউন্টের ব্যালেন্স থেকে কেটে নেয় এবং ডিরেক্টরি সেটআপের একটি লেনদেন নথিভুক্ত করে। এগুলো বর্তমানে কার্যকর পরিমাণ, নতুন মূল্য প্রস্তাব নয়; জমা দেওয়ার আগে আপনার অ্যাকাউন্টের শর্তাবলির সঙ্গে প্রযোজ্য বিলিং মুদ্রা ও সমর্থিত সেবা মিলিয়ে নিশ্চিত করুন।

এই কার্যক্রমে অপারেটরের কাছে জমা দেওয়া, স্থানীয় হালনাগাদ ও বিলিংকে ঘিরে কোনো আইডেমপোটেন্সি কী, একই অর্ডার পুনরায় জমা ঠেকানোর ব্যবস্থা বা সমন্বিত ট্রানজ্যাকশন নেই। পুনরায় করা অনুরোধ সফল হলে অপারেটরের কাছে আবার অনুরোধ জমা পড়তে পারে এবং আবার চার্জ হতে পারে। সময়সীমা পেরিয়ে যাওয়া বা API ত্রুটি প্রমাণ করে না যে অপারেটর আগের অনুরোধ প্রত্যাখ্যান করেছে: স্থানীয় হালনাগাদ ব্যর্থ হওয়ার আগেই সেবাদাতা সেটি গ্রহণ করে থাকতে পারে।

সাড়া

{
  "status": {
    "code": 200,
    "msg": "Success"
  },
  "response": ""
}

স্বাভাবিক সফল সাড়ায় খালি স্ট্রিং থাকে এই ফিল্ডে: response এবং তালিকাভুক্তির কোনো আইডি বা কাজ সম্পন্ন হওয়ার বিস্তারিত ফেরত দেওয়া হয় না। এর অর্থ হলো অপারেটর ও স্থানীয় হালনাগাদের প্রক্রিয়া সফলতার কথা জানিয়েছে; এটি প্রতিটি বাইরের ডিরেক্টরিতে প্রকাশ, তাৎক্ষণিকভাবে সর্বত্র হালনাগাদ পৌঁছানো বা ভবিষ্যতে কলার আইডিতে প্রদর্শনের প্রমাণ নয়।

পুরোনো ব্যবস্থার ত্রুটি

ডিরেক্টরিতে তালিকাভুক্তির API ফলাফলের কোড
API কোডঅর্থ
404অ্যাকাউন্টে নম্বরটি পাওয়া যায়নি, অথবা ফর্মের কোনো আবশ্যক ফিল্ড খালি ছিল।
400অ্যাকাউন্টের ব্যালেন্স বর্তমানে কার্যকর চার্জের চেয়ে কম।
500অপারেটরের কাছে পাঠানো অনুরোধ ব্যর্থ হয়েছে, অথবা অপারেটর অনুরোধটি ইতিমধ্যে গ্রহণ করে থাকতে পারে এমন অবস্থায় স্থানীয় হালনাগাদ ব্যর্থ হয়েছে।
200সফলতার কথা জানানো হয়েছে; সাড়ায় প্রকাশের কোনো নিশ্চয়তা নেই।

দুটিই পড়ুন: HTTP স্ট্যাটাস এবং JSON-এর status.code/status.msg। পরিচয় যাচাই ও উৎস IP-এর বিধিনিষেধের কারণেও ব্যবহারযোগ্য সাড়া পাওয়া নাও যেতে পারে। পুরোনো হ্যান্ডলারে HTTP পদ্ধতি যাচাইয়ের সুস্পষ্ট ব্যবস্থা নেই বলেই হালনাগাদের অনুরোধ করতে GET বা কোয়েরি প্যারামিটার ব্যবহার করবেন না।

আবার চেষ্টা করার আগে যাচাই করুন

  1. অনুরোধ পাঠানোর আগে নিজের মালিকানাধীন নম্বর, অপারেটরের উপযুক্ততা, তালিকাভুক্তির অনুমোদিত তথ্য ও চার্জ নিশ্চিত করুন।
  2. একবার জমা দিন এবং প্রকাশ্য লগ বা বিশ্লেষণব্যবস্থায় গ্রাহকের ঠিকানা প্রকাশ না করে অ্যাকাউন্টের দিকের ফলাফল সংরক্ষণ করুন।
  3. সমর্থিত অ্যাকাউন্ট প্রক্রিয়া বা সহায়তা বিভাগের মাধ্যমে সংরক্ষিত তালিকাভুক্তি ও লেনদেনের ইতিহাস পরীক্ষা করুন। অপারেটরের নিশ্চিত করা প্রক্রিয়াকরণের সময় পর্যন্ত অপেক্ষা করুন; এই API সর্বত্র হালনাগাদ পৌঁছানোর কোনো নিশ্চিত সময়সীমা নির্ধারণ করে না।
  4. ফলাফল অনিশ্চিত হলে আবার চেষ্টা করার আগে সহায়তা বিভাগকে অপারেটরের অর্ডার ও স্থানীয় বিলিং মিলিয়ে দেখতে বলুন। একই অনুরোধ পুনরায় করা এমন কোনো স্ট্যাটাস পরীক্ষা নয় যা বারবার করলেও অতিরিক্ত প্রভাব ফেলে না।