Отримати дані про проєкт перенесення номерів

Доступ до облікового запису та проєкту

Використовуйте ввімкнений обліковий запис API через HTTPS з дозволеної IP-адреси. Проєкт має належати цьому обліковому запису й не має бути видаленим. Використовуйте унікальний ідентифікатор проєкту з процесу оформлення замовлення на перенесення, а не його числовий ідентифікатор у базі даних чи номер телефону. Під час формування запиту застосовуйте URL-кодування до ідентифікатора проєкту.

Запит

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/v3/lnp/project/$PROJECT_ID"

Обробляйте цю відповідь як конфіденційну

Повна відповідь містить платіжні дані оператора, від якого переносять номери, зокрема збережене значення billing_pin, дані платіжного облікового запису, телефону, адреси, компанії та уповноваженої контактної особи. API не маскує ці поля. Запитуйте лише статус або список номерів, якщо цього достатньо для вашого робочого процесу. Не зберігайте повну детальну відповідь у сховищі браузера, системах аналітики чи загальнодоступних журналах і не включайте її до знімків екрана для служби підтримки; показуйте лише ті поля, які потрібні клієнту з відповідними правами доступу.

Структура відповіді

Вигаданий приклад з окремими полями; у відповіді можуть повертатися й додаткові поля.

{
  "status": {
    "code": 200,
    "msg": "Project Detail"
  },
  "response": {
    "project": {
      "id": 11,
      "uniqueid": "PROJECT_EXAMPLE",
      "project_name": "Example transfer",
      "location": "US",
      "status": 0,
      "status_str": "Pending"
    },
    "counts": {
      "total": 0,
      "pending": 0,
      "in_progress": 0,
      "completed": 0,
      "rejected": 0
    },
    "numbers": [],
    "events": [],
    "uploads": []
  }
}

Цей приклад навмисно неповний: у ньому пропущено всі платіжні облікові дані та особисті контактні дані. Їхня відсутність у прикладі не означає, що в реальній відповіді їх приховано.

Розділи детальних даних проєкту
Розділ	Вміст
project	Числовий ідентифікатор рядка, унікальний ідентифікатор проєкту, назва проєкту, місцезнаходження, збережені платіжні, контактні й адресні дані, час створення та обчислений статус. Застаріле поле оператора, від якого переносять номери, записується як loosing_carrier.
counts	Загальна кількість рядків номерів і лічильники статусів Pending, In Progress, Completed та Rejected.
numbers	Той самий набір даних про номери, що й у кінцевій точці списку номерів проєкту, включно з коментарями клієнта та збереженими значеннями планування.
events	Збережені рядки подій і поля даних у необробленому та розібраному вигляді, на які поширюються обмеження видимості й формату кінцевої точки подій.
uploads	Метадані документів: числовий ідентифікатор, upload_type, file_name, file_extension, date_created та відносна адреса download_url. Для доступу за цією URL-адресою все одно потрібна автентифікація облікового запису.

Тлумачення зведення та метаданих

Під час обчислення статусу пріоритет має In Progress, потім Pending, потім Completed, потім Rejected; якщо жоден із них не підходить, використовується Pending. Зведений статус Completed можливий навіть за наявності відхилених номерів. Перевіряйте лічильники та статуси номерів, а не припускайте, що перенесення кожного номера завершено.

Відповідь містить метадані документів, а не байти файлів. У ній немає ані поділу на сторінки, ані курсора для інкрементального отримання даних. Запити детальних даних і списку виконують окремі операції читання, а не створюють єдиний знімок із гарантованою транзакційною узгодженістю. Дати залишаються такими, як їх збережено; перетворення часового поясу не задокументовано. Для маршрутів проєкту використовуйте uniqueid; його не можна замінити числовим ідентифікатором проєкту.

Помилки та обмеження

Перевіряйте як відповідь HTTP, так і status.code/status.msg. Якщо проєкт відсутній, видалений або не належить обліковому запису, повертається код API 404 з повідомленням про те, що проєкт не знайдено. Також діють вимоги автентифікації та обмеження за IP-адресою джерела. Приклади не виконують реальних запитів, а успішна відповідь не доводить, що оператор прийняв або завершив перенесення.

Наслідки та робочий процес

Це канонічний маршрут детальних даних, який поточний портал використовує в поданні замовлення на перенесення. Портал зіставляє поля зі своїм інтерфейсом і застосовує власний набір даних для клієнта; не припускайте, що необроблена відповідь API ідентична даним JSON порталу або їх відображенню. Перевірений обробник детальних даних не змінює проєкт і безпосередньо не ініціює ані запит до оператора, ані стягнення плати.