আপনার বার্তার পেছনের ব্যবসা নিবন্ধন করুন
একটি মেসেজিং ব্র্যান্ড US 10DLC বার্তা পাঠানো ব্যবসাকে চিহ্নিত করে। প্রচারণার ব্যবহার-ক্ষেত্র বেছে নেওয়ার আগে ব্র্যান্ড নিবন্ধন করুন। ব্যবসার আইনি তথ্য এবং প্রয়োজনীয় যাচাইকরণ সম্পন্ন করতে পারেন এমন একজন যোগাযোগকারী ব্যবহার করুন। ফেরত দেওয়া ব্র্যান্ড ID নিজে থেকে বার্তা পাঠানোর অনুমোদন নয়।
সক্রিয় API অ্যাকাউন্ট এবং এর অনুমোদিত উৎস IP ঠিকানা সহ HTTPS-এর মাধ্যমে এই বর্তমান অ্যাকাউন্ট-মালিকানাধীন রুট ব্যবহার করুন। user_id, username বা অন্য গ্রাহকের মালিক শনাক্তকারী জমা দেবেন না। MultiTEL প্রমাণীকৃত অ্যাকাউন্ট থেকে মালিকানা নথিভুক্ত করে।
একটি স্পষ্ট স্যান্ডবক্স অনুরোধ দিয়ে শুরু করুন
পোর্টাল তার ফর্ম ডিফল্টভাবে স্যান্ডবক্স mode-এ রাখে; মক ব্র্যান্ডের উদ্দেশ্যে সরাসরি API অনুরোধে JSON বুলিয়ান mock: true স্পষ্টভাবে অন্তর্ভুক্ত করতে হবে। সেই ফ্ল্যাগ বাদ দেওয়া স্যান্ডবক্সের নিশ্চয়তা নয় এবং বিলযোগ্য প্রোডাকশন নিবন্ধন তৈরি করতে পারে। পোর্টালের mode ক্ষেত্র API-এর mock ক্ষেত্রের বিকল্প নয়।
নিচের ক্ষেত্রগুলো ব্যবহার করে স্থানীয় brand.json ফাইল প্রস্তুত করুন। প্লেসহোল্ডারগুলো উপযুক্ত পরীক্ষার তথ্য এবং বর্তমান ক্যাটালগ কোড দিয়ে প্রতিস্থাপন করুন। এই উদাহরণটি একটি বেসরকারি-লাভজনক ব্যবসা; অন্য সত্তা-ধরনের প্রয়োজনীয়তা ভিন্ন।
{
"entityType": "PRIVATE_PROFIT",
"displayName": "Example business",
"companyName": "Example legal business name",
"ein": "YOUR_TAX_ID",
"einIssuingCountry": "US",
"phone": "+12025550123",
"street": "123 Example Street",
"city": "Example City",
"state": "NY",
"postalCode": "10001",
"country": "US",
"email": "contact@example.invalid",
"brandRelationship": "BASIC_ACCOUNT",
"vertical": "CURRENT_VERTICAL_CODE",
"referenceId": "your-business-reference",
"mock": true
}উপরের ব্যবসা, ঠিকানা, ফোন এবং শনাক্তকারী হলো প্লেসহোল্ডার, নিবন্ধন-প্রস্তুত ব্যবসায়িক পরিচয় নয়। entityType, vertical, country, state, brandRelationship এবং অন্যান্য এনুমারেশনের বর্তমান মানের জন্য দেখুন মেসেজিং ক্যাটালগসমূহ.
curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
--header 'Content-Type: application/json' \
--header "Idempotency-Key: $IDEMPOTENCY_KEY" \
--data-binary @brand.json \
'https://api.multitel.net/tcr/v2/brand/nonBlocking'ব্যবসা ও যোগাযোগের ক্ষেত্রসমূহ
| ক্ষেত্রসমূহ | যা দিতে হবে |
|---|---|
| entityType, displayName | বর্তমান সত্তা-ধরনের কোড এবং চেনা যায় এমন ব্র্যান্ড নাম। সর্বাধিক দৈর্ঘ্য যথাক্রমে 20 এবং 255 অক্ষর। |
| country, street, city, state, postalCode | প্রকৃত ব্যবসায়িক ঠিকানা। প্রযোজ্য হলে দুই-অক্ষরের দেশের কোড এবং বর্তমান US state কোড ব্যবহার করুন। সীমা: street 255, city 100, state 20 এবং postalCode 10 অক্ষর। |
| email, phone | একটি সক্রিয় যোগাযোগের ইমেল, সর্বাধিক 100 অক্ষর পর্যন্ত, এবং আন্তর্জাতিক +কান্ট্রি-কোড ফরম্যাটে একটি ফোন নম্বর, সর্বাধিক 20 অক্ষর পর্যন্ত। নিবন্ধন জুড়ে ব্যবসার তথ্য সামঞ্জস্যপূর্ণ রাখুন। |
| companyName, ein, einIssuingCountry | সংস্থার ক্ষেত্রে, আইনি কোম্পানির নাম এবং ব্যবসায়িক কর শনাক্তকারী দিন। শনাক্তকারীর ইস্যুকারী দেশ একটি পৃথক দুই-অক্ষরের ক্ষেত্র। সীমা: companyName 255 এবং ein 21 অক্ষর। একক মালিক সংস্থার কর পরিচয়ের পরিবর্তে ব্যক্তিগত-নামের ক্ষেত্র ব্যবহার করেন। |
| brandRelationship, vertical | বর্তমান ক্যাটালগ কোড ব্যবহার করে ব্যবসার সাথে সম্পর্ক এবং এর শিল্প। সংস্থাগুলোর জন্য এগুলো আবশ্যক; একক-মালিকের নিয়ম ভিন্ন। API কোডের জন্য অনূদিত প্রদর্শন লেবেল প্রতিস্থাপন করবেন না। |
| firstName, lastName, mobilePhone | একক মালিকের জন্য আবশ্যক। নামের ক্ষেত্রগুলোতে প্রতিটিতে সর্বাধিক 100 অক্ষর পর্যন্ত দেওয়া যায়। প্রয়োজনীয় OTP যাচাইকরণের জন্য আন্তর্জাতিক ফরম্যাটে একটি যোগ্য মোবাইল নম্বর দিন। |
| stockSymbol, stockExchange, website, businessContactEmail | একটি পাবলিক কোম্পানির অতিরিক্ত যাচাইকরণ প্রক্রিয়ার জন্য স্টক প্রতীক/এক্সচেঞ্জ, website এবং একটি যোগ্য ব্যবসায়িক-যোগাযোগ ইমেলও প্রয়োজন। সীমা: stockSymbol 10, website 255 এবং businessContactEmail 255 অক্ষর। |
| altBusinessIdType, altBusinessId | ঐচ্ছিক বিকল্প ব্যবসায়িক শনাক্তকারী। এর ধরন ও মান একসাথে দিন। বর্তমান ধরনের ক্যাটালগ ব্যবহার করুন; মানে সর্বাধিক 50 অক্ষর পর্যন্ত দেওয়া যায়। |
| referenceId | আপনার ব্যবসায়িক রেফারেন্স, সর্বাধিক 50 অক্ষর পর্যন্ত। বর্তমান সত্তা-নির্দিষ্ট প্রয়োজনীয়তা অনুযায়ী একক-মালিক নিবন্ধনের জন্য এটি অন্তর্ভুক্ত করুন। এটি ব্যবসায়িক মেটাডেটা, অনুরোধের আইডেম্পোটেন্সি কী নয়। |
| website, ipAddress, tag | প্রযোজ্য হলে অতিরিক্ত ওয়েবসাইট, উৎপত্তি-IP মেটাডেটা এবং ট্যাগ মান। এগুলো অ্যাকাউন্ট মালিকানা প্রতিষ্ঠা করে না বা পরিচয় পরীক্ষার বিকল্প হয় না। |
| mock | একটি JSON বুলিয়ান। উদ্দেশ্যমূলক মক ওয়ার্কফ্লোর জন্য শুধু true ব্যবহার করুন; স্পষ্টভাবে পর্যালোচিত প্রোডাকশন নিবন্ধনের জন্য false ব্যবহার করুন। JSON বুলিয়ানের বিকল্প হিসেবে "false" স্ট্রিং পাঠাবেন না। |
একক মালিক US বা কানাডীয় নিবন্ধনের জন্য সমর্থিত এবং প্রচারণার যোগ্যতার আগে OTP যাচাইকরণ প্রয়োজন। পাবলিক কোম্পানির ব্যবসায়িক-যোগাযোগ যাচাইকরণ ধাপ প্রয়োজন হতে পারে। GOVERNMENT US-ভিত্তিক সরকারি সত্তার জন্য; অন্যান্য সংস্থার জন্য সঠিক সত্তা বিভাগ নিশ্চিত করুন। সত্তা-নির্দিষ্ট প্রয়োজনীয়তার পাশাপাশি ফেরত দেওয়া যাচাইকরণ ত্রুটিগুলো অনুসরণ করুন।
একটি স্থিতিশীল আইডেম্পোটেন্সি কী রাখুন
এই উদ্দেশ্যমূলক নিবন্ধনের জন্য একটি Idempotency-Key তৈরি করুন। এতে স্পেস ছাড়া 1–128টি মুদ্রণযোগ্য ASCII অক্ষর থাকতে হবে। একই HTTP পদ্ধতি, পাথ, ক্যোয়ারি স্ট্রিং এবং হুবহু অনুরোধ-বডি বাইটের সাথে শুধু একই কী পুনরায় ব্যবহার করুন। অর্থ না বদলেও JSON পুনর্গঠন করলে অনুরোধের ফিঙ্গারপ্রিন্ট বদলে যায়।
সম্পন্ন কীযুক্ত অনুরোধ আরেকটি নিবন্ধন জমা ছাড়াই এর সংরক্ষিত প্রতিক্রিয়া পুনরায় চালাতে পারে। এখনও প্রক্রিয়াধীন ডুপ্লিকেট HTTP 409 ফেরত দেয় এবং Retry-After অন্তর্ভুক্ত করতে পারে। একই কীসহ পরিবর্তিত অনুরোধ বিরোধপূর্ণ হয়। অনুরোধের সময় শেষ হয়েছে বা ত্রুটি ফিরেছে বলে শুধু নতুন কী তৈরি করবেন না: ব্যবসা হয়তো ইতিমধ্যে নিবন্ধিত হয়েছে।
সেই অনুরোধ সমাধান করার সময় brand.json অপরিবর্তিত রাখুন। ক্যাশ করা 500 বা 502 ত্রুটি নিবন্ধন পুনরায় চেষ্টা করার পরিবর্তে মূল ত্রুটিই পুনরায় চালাতে পারে। ফেরত দেওয়া যেকোনো brandId, requestId এবং পারস্পরিক সম্পর্কের হেডার সংরক্ষণ করুন; ভিন্ন অনুরোধ শুরু করার আগে বিদ্যমান ব্র্যান্ডের প্রকৃত অবস্থা পরীক্ষা করুন এবং কোনো অসামঞ্জস্য থাকলে তা মিটিয়ে নিন।
ব্র্যান্ড এবং এর অবস্থা পড়ুন
এই API v3 status/response খামের পরিবর্তে HTTP স্থিতি কোড এবং সরাসরি JSON বডি ব্যবহার করে। সফল নিবন্ধন brandId সহ একটি ব্র্যান্ড অবজেক্ট ফেরত দেয়। সেই শনাক্তকারী সংরক্ষণ করুন এবং ফেরত দেওয়া যাচাইকরণ বা পরিচয়ের অবস্থা পরীক্ষা করুন। অতিরিক্ত ক্ষেত্র সত্তা এবং নিবন্ধনের অবস্থার উপর নির্ভর করে।
curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
"https://api.multitel.net/tcr/v2/brand/$BRAND_ID"শুধু আপনার অ্যাকাউন্টের ব্র্যান্ড পড়ুন। 404-এর অর্থ হতে পারে ব্র্যান্ডটি এই অ্যাকাউন্টের জন্য উপলব্ধ নয়। প্রয়োজনীয় যাচাইকরণ সম্পন্ন করুন, তারপর ব্র্যান্ড যোগ্যতা ব্যবহার করে এর উপলব্ধ প্রচারণা ব্যবহার-ক্ষেত্র খুঁজুন। মক সংস্থান প্রোডাকশন পাঠানোর জন্য যোগ্য বলে ধরে নেওয়া যায় না।
প্রোডাকশন ফি
| নিবন্ধন | ফি |
|---|---|
| মানক সংস্থা | $5.00 |
| একক মালিক | $4.45 |
| মক ব্র্যান্ড | মক ওয়ার্কফ্লোতে কোনো ব্র্যান্ড-নিবন্ধন ডেবিট নেই |
এই খুচরা পরিমাণগুলো 24 অক্টোবর 2026 তারিখে বর্তমান পোর্টাল কনফিগারেশনের সাথে মিলিয়ে দেখা হয়েছে। প্রোডাকশন নিবন্ধনের আগে পোর্টালে বর্তমান ফি নিশ্চিত করুন। প্রচারণার চার্জ, অতিরিক্ত যাচাই এবং মেসেজিং ব্যবহার আলাদা। প্রোডাকশন নিবন্ধন জমা দেওয়ার আগে ক্রয়ের অনুমতি এবং উপলব্ধ তহবিল পরীক্ষা করে; রেজিস্ট্রিতে সফলভাবে ব্র্যান্ড নিবন্ধন এবং স্থানীয় বিলিং পৃথক প্রক্রিয়াকরণ ধাপ, তাই ত্রুটি বা বিলিং সমস্যা হলে সংস্থান ID সংরক্ষণ করুন এবং লেনদেন মিলিয়ে নিন।
মক ব্র্যান্ডকে প্রোডাকশনে পরিবর্তন করা একটি পৃথকভাবে নিশ্চিত ওয়ার্কফ্লো এবং এটি নতুন প্রোডাকশন পরিচয় ও চার্জ তৈরি করতে পারে। পরবর্তী অনুরোধে mock থেকে false-এ সম্পাদনা করলে বিদ্যমান ব্র্যান্ড রূপান্তরিত হয় বলে ধরে নেবেন না।
ব্র্যান্ড ডুপ্লিকেট না করে ত্রুটিগুলো সামলান
| HTTP ফলাফল | যা পরীক্ষা করবেন |
|---|---|
| 400 | ক্ষেত্রের ত্রুটিগুলো পড়ুন। রেজিস্ট্রি যাচাইকরণ ত্রুটি code/description অবজেক্টের অ্যারে হতে পারে। স্থানীয় আইডেম্পোটেন্সি-কী যাচাইকরণও 400 ফেরত দিতে পারে। |
| 401, 403 অথবা 404 | API শংসাপত্র, API অ্যাকাউন্টের অনুমোদিত উৎস IP, গ্রাহকের অনুমতি ও মালিকানা পরীক্ষা করুন। রেজিস্ট্রি প্রতিক্রিয়াতেও নিজস্ব অনুমোদন ত্রুটি থাকতে পারে। |
| 402 | তহবিল এবং ক্রয়ের অনুমতি পর্যালোচনা করুন। তহবিলহীন প্রোডাকশন অনুরোধকে স্যান্ডবক্স পরীক্ষা হিসেবে গণ্য করবেন না। |
| 409 | চলমান অনুরোধের জন্য অপেক্ষা করার সময় একই কী এবং অপরিবর্তিত অনুরোধ রাখুন। পরিবর্তিত বডি/কী নিয়ে বিরোধ বা পুনরুদ্ধার-অযোগ্য পূর্ববর্তী প্রতিক্রিয়া থাকলে, আগে অনুরোধের প্রকৃত অবস্থা পরীক্ষা করে কোনো অসামঞ্জস্য মিটিয়ে নিতে হবে। |
| 429 অথবা সীমাবদ্ধকারী-অনুপলব্ধ প্রতিক্রিয়া | উপস্থিত থাকলে Retry-After মানুন। সীমা পরিষ্কার হওয়ার পর একই উদ্দেশ্যমূলক অনুরোধ ও কী পুনরায় চেষ্টা করুন। |
| 500 অথবা 502 | দূরবর্তী অপারেশন হয়তো গৃহীত হয়েছে। স্থানীয়-প্রক্রিয়াকরণ ত্রুটিতে requestId অন্তর্ভুক্ত থাকতে পারে। এটি সংরক্ষণ করুন এবং বিদ্যমান সংস্থান পরীক্ষা করুন; প্রতিস্থাপন নিবন্ধন প্রয়োজন বলে ধরে নেবেন না। |