Подайте данни за вписване на телефонен номер в указател

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

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

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

Изисквания за акаунта и номера

Използвайте активиран API акаунт през HTTPS от разрешен изходен IP адрес. Точно този номер трябва да е неанулиран запис за закупен номер, принадлежащ на този акаунт. Използвайте всички цифри на международния номер от регистъра си, например формата с код на държава 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 са повърхностни: те не установяват дали адресът е валиден или се приема от оператора, а старият уебсайт е прилагал различни изисквания към формуляра.

Реализацията може да изведе предупреждение за липсващ ключ в масив, когато незадължително обозначение за посока липсва или е празно. Ако отговорът е с неправилен формат или операторът отхвърли адреса, запазете референцията на заявката и помолете поддръжката да потвърди вписването, вместо многократно да подавате предполагаеми поправки на адреса.

Таксуване и повторни опити

Прегледаният обработчик проверява за наличност на поне 10.00 единици от салдото преди да се свърже с оператора. След като операторът и локалната актуализация на номера отчетат успех, той приспада 10.00 от салдото по акаунта и записва транзакция за създаване на вписване в указател. Това са сумите, прилагани в текущата реализация, а не ново ценово предложение; преди подаване потвърдете приложимата валута за таксуване и поддържаната услуга според условията на акаунта си.

Операцията няма ключ за идемпотентност, защита срещу дублирани поръчки или транзакция, обхващаща подаването към оператора, локалната актуализация и таксуването. Успешна повторна заявка може да доведе до ново подаване към оператора и нова такса. Изтичане на времето за изчакване или грешка в API не доказва, че операторът е отхвърлил предишната заявка: доставчикът може да я е приел, преди локалната актуализация да е завършила неуспешно.

Отговор

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

Обичайният отговор при успех съдържа празен низ в полето response и не връща идентификатор на вписването или подробности за приключването. Това означава, че обработката при оператора и локалната актуализация са отчели успех; то не доказва публикуване във всеки външен указател, незабавно разпространение на промяната или бъдещо показване на идентификацията на обаждащия се.

Грешки в старата реализация

Проверете както статуса HTTP, така и полетата в JSON status.code/status.msg. Удостоверяването и ограниченията за изходния IP адрес също могат да попречат на получаването на използваем отговор. Не използвайте GET или параметри на заявката в адреса, за да поискате актуализация, само защото старият обработчик няма изрична проверка на метода HTTP.

Проверете, преди да опитате отново

1. Преди да изпратите заявката, потвърдете номера, който притежавате, допустимостта при оператора, одобрените данни за вписване и таксата.
2. Подайте заявката веднъж и запазете резултата от страната на акаунта, без да разкривате адреса на клиента в публични регистрационни файлове или аналитични данни.
3. Проверете запазеното вписване и историята на транзакциите чрез поддържания процес в акаунта или чрез поддръжката. Изчакайте потвърдения от оператора срок за обработка; този API не определя гарантиран срок за разпространение на промяната.
4. Когато резултатът е несигурен, помолете поддръжката да съпостави и изясни поръчката при оператора и локалното таксуване, преди да опитате отново. Повторната заявка не е идемпотентна проверка на статуса.