Прочетете изискванията за кампания на дадена марка

Пазете марката и случая на употреба заедно

Използвайте ID на марката от вашия акаунт и стойност за случай на употреба, върната от списъка за квалификация на същата марка. Работният процес на клиента проверява собствеността преди заявката към доставчика. Потвърдете, че полето usecase на върнатия обект съвпада с избраната стойност. Справка за една марка или случай на употреба не установява изисквания за друга.

Прочетете текущите изисквания

Прилагайте изискванията на избраните оператори заедно

Изискванията на операторите могат да се различават. Когато не е подаден изричен списък с оператори, порталът взема предвид всички метаданни за оператори в отговора; непразен списък ограничава проверките до тези избрани ID. Не използвайте само броя образци или декларациите на първия оператор. Изберете оператори от отговора, проверете поддръжката и квалификацията, изпълнете най-високия приложим минимум за образци и удовлетворете изискваните декларации за включване, отписване и помощ в рамките на този избор. Порталът отхвърля избрани ID на оператори, които липсват в текущия отговор, и отхвърля избор без допустим оператор.

Изискванията описват какво трябва да бъде предоставено; те не доказват, че процесът за съгласие на клиента или съдържанието на кампанията отговарят на тези изисквания. Съберете верни, представителни образци и декларации. Не включвайте автоматично декларации, за да премине формулярът.

Подгответе образци и отговори към абонатите

Текущият формуляр за кампания използва sample1 до sample5 за образци на съобщения. Ако изискванията не могат да бъдат изпълнени в рамките на наличния формуляр, спрете и изяснете избора с поддръжката. За активирана декларация на абоната предоставете съответните ключови думи и текст на отговора: optinKeywords/optinMessage, optoutKeywords/optoutMessage и helpKeywords/helpMessage. Поддържайте образците съгласувани с избрания случай на употреба и реалните съобщения към клиентите.

Прегледайте преди всяка заявка за регистрация

Обновете изискванията, когато марката, случаят на употреба или изборът на оператори се промени. Порталът повторно валидира избрания случай на употреба, броя под-случаи на употреба, допустимостта на операторите, образците и декларациите преди създаване. Прегледайте ценообразуването на акаунта и условията за регистрация отделно. Тази GET заявка не регистрира и не одобрява кампания, не я споделя с оператора за съобщения и не присвоява телефонен номер. Създаването и провизирането са отделни операции.

Обработка на неуспешна справка за изисквания

Ако заявката е неуспешна, върне неочакван JSON или не съвпада с избрания случай на употреба, оставете формуляра непълен и позволете на клиента да опита отново, след като грешката бъде отстранена. Не заменяйте недостъпни изисквания с празен обект и не приемайте, че липсващи данни означават липса на изисквания. Съобразявайте се с Retry-After и използвайте отлагане при ограничения на честотата и откази на наличността.

Заявка

Използвайте активиран API акаунт през HTTPS от разрешен IP адрес на източника. Текущият маршрут поддържа политиката за удостоверяване на акаунта, включително Basic удостоверяване и активирани bearer API акаунти. Не използвайте идентификационни данни на доставчика.

GET с ID на марката и избраната стойност за случай на употреба в URL пътя. Не се изисква тяло на заявката.

curl --fail-with-body --silent --show-error \
  --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/campaignBuilder/brand/$BRAND_ID/usecase/$USECASE"

Отговор

Текущият TCR маршрут връща JSON тялото от регистъра директно и запазва неговия HTTP статус. Той не добавя наследената v3 обвивка status/response. Съкратеният измислен пример не е реален резултат от квалификация. Проверете HTTP статуса и очакваната JSON структура, преди да го използвате. Порталът очаква обект, чийто usecase съвпада с избрания случай на употреба. Изискванията на операторите са под mnoMetadata, индексирани по ID на оператора. Примерното ID на оператора и изискванията са измислени. Може да бъдат върнати и други полета на доставчика.

Илюстративна структура на отговора; не са реални данни от акаунта или текуща оферта.

{
  "usecase": "2FA",
  "minSubUsecases": 0,
  "maxSubUsecases": 0,
  "mnoMetadata": {
    "12345": {
      "mnoSupport": true,
      "qualify": true,
      "minMsgSamples": 1,
      "reqSubscriberOptin": true,
      "reqSubscriberOptout": true,
      "reqSubscriberHelp": true,
      "noEmbeddedLink": false,
      "noEmbeddedPhone": false
    }
  }
}

Грешки

• 401: Удостоверяването на акаунта е неуспешно. Проверете API идентификационните данни, състоянието на активиране и приложимите ограничения за IP адрес на източника.
• 404: Марката не е свързана с удостоверения акаунт или доставчикът не може да намери заявената марка или избор. Локален отказ за собственост се връща преди заявка към доставчика.
• Други грешки на регистъра: HTTP статусът и тялото от горния поток се запазват. Невалиден или недостъпен случай на употреба не е успешен празен набор от изисквания.
• 429: Достигнат е лимитът на заявки за акаунта или споделеният лимит на доставчика. Съобразявайте се с Retry-After.
• 502/503: Отказ на наличността на транспорта, доставчика или ограничителя на честотата. Запазете формуляра и опитайте отново с отлагане.

Наличност и странични ефекти

• Прегледаната GET заявка проверява съществуващата собственост върху марката, свързва се с регистъра и записва одитни записи на заявките. Тя не създава марка или кампания и не начислява такса за регистрация.
• Метаданните за таксите на доставчика не са оферта на дребно за клиента на MultiTEL. Порталът преглежда ценообразуването на акаунта отделно преди последваща заявка за регистрация.
• Квалификацията и изискванията могат да се променят. Обновете ги за избраната марка и случай на употреба преди подаване. Успешна справка не е одобрение на кампания, присвояване на номер или разрешение за започване на изпращане на съобщения.