დაარეგისტრირეთ ბიზნესი თქვენი შეტყობინებების უკან
შეტყობინებების ბრენდი იდენტიფიცირებს ბიზნესს, რომელიც აგზავნის US 10DLC შეტყობინებებს. დაარეგისტრირეთ ბრენდი კამპანიის გამოყენების შემთხვევის არჩევამდე. გამოიყენეთ ბიზნესის იურიდიული მონაცემები და საკონტაქტო პირი, რომელსაც შეუძლია ნებისმიერი საჭირო ვალიდაციის დასრულება. დაბრუნებული ბრენდის ID თავისთავად არ არის შეტყობინებების გაგზავნის ნებართვა.
გამოიყენეთ ეს მიმდინარე ანგარიშზე მიკუთვნებული მარშრუტი HTTPS-ის მეშვეობით, ჩართული API ანგარიშით და მისი ნებადართული წყაროს IP მისამართით. არ გაგზავნოთ 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 მკაფიოდ განხილული პროდუქციული რეგისტრაციისთვის. არ გაგზავნოთ სტრიქონი "false" JSON ბულეანის შემცვლელად. |
ინდივიდუალური მეწარმეები მხარდაჭერილია US ან კანადური რეგისტრაციებისთვის და საჭიროებენ OTP დადასტურებას კამპანიის უფლებამოსილებამდე. საჯაროდ ვაჭრობადი აქციების მქონე კომპანიებს შეიძლება დასჭირდეთ ბიზნეს-საკონტაქტო ვალიდაციის ნაბიჯი. GOVERNMENT განკუთვნილია US-ში დაფუძნებული სამთავრობო სუბიექტებისთვის; დაადასტურეთ სწორი სუბიექტის კატეგორია სხვა ორგანიზაციებისთვის. დაიცავით სუბიექტზე სპეციფიკური მოთხოვნები და დაბრუნებული ვალიდაციის შეცდომები.
შეინარჩუნეთ სტაბილური იდემპოტენტობის გასაღები
შექმენით ერთი Idempotency-Key ამ დაგეგმილი რეგისტრაციისთვის. ის უნდა შეიცავდეს 1–128 დასაბეჭდ ASCII სიმბოლოს ინტერვალების გარეშე. იგივე გასაღები ხელახლა გამოიყენეთ მხოლოდ იგივე HTTP მეთოდთან, გზასთან, მოთხოვნის სტრიქონთან და მოთხოვნის სხეულის ზუსტ ბაიტებთან ერთად. JSON-ის გადაფორმატება, მისი მნიშვნელობის შეუცვლელადაც კი, ცვლის მოთხოვნის თითის ანაბეჭდს.
დასრულებულ გასაღებიან მოთხოვნას შეუძლია თავისი შენახული პასუხის გამეორება სხვა რეგისტრაციის გაგზავნის გარეშე. დამუშავებაში მყოფი დუბლიკატი აბრუნებს HTTP 409-ს და შეუძლია შეიცავდეს Retry-After. შეცვლილი მოთხოვნა იგივე გასაღებით კონფლიქტშია. არ შექმნათ ახალი გასაღები მხოლოდ იმიტომ, რომ მოთხოვნას ვადა გაუვიდა ან შეცდომა დააბრუნა: ბიზნესი შესაძლოა უკვე რეგისტრირებულია.
შეინარჩუნეთ brand.json უცვლელად ამ მოთხოვნის მოგვარებისას. ქეშირებულ 500 ან 502-ს შეუძლია თავდაპირველი შეცდომის გამეორება რეგისტრაციის ხელახალი მცდელობის ნაცვლად. შეინახეთ ნებისმიერი დაბრუნებული brandId, requestId და კორელაციის სათაურები; შეაჯერეთ არსებული ბრენდი სხვა მოთხოვნის დაწყებამდე.
წაიკითხეთ ბრენდი და მისი სტატუსი
ეს API იყენებს HTTP სტატუსის კოდებს და პირდაპირ JSON სხეულს და არა v3 status/response კონვერტს. წარმატებული რეგისტრაცია აბრუნებს ბრენდის ობიექტს, რომელიც შეიცავს 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. შეინახეთ ის და შეამოწმეთ არსებული რესურსი; არ ივარაუდოთ, რომ ჩანაცვლებითი რეგისტრაციაა საჭირო. |