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

Подайте запис до довідника оператора

Подайте ім’я або назву й адресу для запису в довіднику, пов’язаного з належним вам у 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. Якщо результат невизначений, перед повторною спробою попросіть службу підтримки звірити замовлення в оператора з локальними даними про списання коштів. Повторний запит не є ідемпотентною перевіркою статусу.