Створення реєстраційного профілю

Створюйте профіль лише один раз

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

Успішна відповідь на створення не є регуляторним схваленням чи активацією номера. Збережіть UUID документа, ID ідентичності та ID адреси окремо: вони призначені для різних цілей. Цей запит змінює дані облікового запису і не є операцією лише для перевірки.

Запит на створення

Автентифікуйтеся за допомогою свого увімкненого облікового запису MultiTEL API та дозволеної для нього IP-адреси. У прикладах використовуються облікові дані HTTP Basic, збережені у змінних середовища. Перевіряйте і HTTP-відповідь, і JSON-поле status.code; сама по собі відповідь HTTP 200 не підтверджує успіх. Усі значення в прикладах вигадані.

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --header 'Content-Type: application/json' \
  --data @registration-profile.json \
  https://api.multitel.net/v3/create_document

{
  "identity_type": "Personal",
  "first_name": "Example",
  "last_name": "Person",
  "phone_number": "12025550123",
  "email": "end-user@example.com",
  "city": "Example City",
  "postal_code": "00000",
  "country": "US",
  "address": "1 Example Street",
  "nationality": "US",
  "signature": "BASE64_PNG_OF_THE_AUTHORIZED_END_USER_SIGNATURE"
}

Цей JSON є ілюстративним профілем Personal, а не справжньою ідентичністю, готовою до подання. Замініть його дані та підпис інформацією про кінцевого користувача, якої вимагають вибрані правила реєстрації. Також підтримується введення у форматі form-encoded.

Цей прямий обробник v3 вимагає полів адреси і створює адресу. Не припускайте, що через нього доступний портальний параметр відкладення адреси.

Збережіть усі три ідентифікатори

Нижче показано лише вибрані поля відповіді; фактична відповідь також містить подану інформацію профілю та дані підпису. Поводьтеся з повною відповіддю як із приватною.

{
  "status": {
    "code": 200,
    "msg": "Success Create Registration Detail."
  },
  "response": {
    "uuid": "11111111111111111111111111111111",
    "identity_id": "22222222222222222222222222222222",
    "address_id": "33333333333333333333333333333333",
    "country_iso": "US",
    "email": "end-user@example.com"
  }
}

• response.uuid ідентифікує локальний профіль. Використовуйте його з get_document. У відповідях documents і get_document той самий ідентифікатор профілю має назву id.
• response.identity_id ідентифікує ідентичність для подальших підтверджень ідентичності і супровідних документів.
• response.address_id ідентифікує створену адресу. Зберігайте його окремо; UUID локального профілю не є ID адреси. Сумісність подальшого долучення підтверджень адреси для новостворених профілів ще переглядається.

Дві кінцеві точки зчитування профілю не повертають identity_id чи address_id, тому збережіть початкову успішну відповідь на створення. Якщо її втрачено, скористайтеся переглядом документів у порталі або зверніться до служби підтримки, перш ніж створювати замінний профіль.

Розширений сценарій: долучення попередньо завантажених підтверджень під час створення

Ви можете передати identity_encryptfiles і address_encryptfiles як масиви ID, які повертає create_encrypt_files. Завантажуйте файли з типом підтвердження для відповідної категорії сутності, а потім подавайте запит до закінчення приблизно 20-хвилинного терміну дії посилання на файл. Обробник створення перевіряє обліковий запис, категорію та термін дії кожного переданого посилання.

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

Якщо пізніше підтвердження адреси для новоствореної адреси відхилено, не підставляйте UUID профілю і не створюйте ідентичність повторно. Зупиніться і перевірте профіль у порталі або зі службою підтримки. Шлях зчитування та пошуку підтверджень адреси залишається обмеженням перегляду.

Збої та часткове створення

Код API 400 охоплює помилки перевірки полів, збої створення в оператора та збої локального збереження. Помилки перевірки можуть з'являтися як записи з ключами полів у response. Код 500 використовується для недоступної чи недійсної країни реєстрації, а код 404 для відсутніх або прострочених попередньо завантажених посилань. Читайте status.msg, а не лише код.

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