Създаване на регистрационен профил

Създайте профила само веднъж

Тази заявка създава локален регистрационен профил заедно със записи за самоличност и адрес при оператора. Започнете с актуалните държави за регистрация, типове номера и изисквания. Изискванията зависят от държавата и типа на номера, който планирате да регистрирате.

Успешен отговор при създаване не е регулаторно одобрение, нито активиране на номер. Запазете 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 профил, а не истинска самоличност, готова за подаване. Заменете неговите данни и подпис с информацията за крайния потребител, изисквана от избраните правила за регистрация. Поддържа се и вход, кодиран като формуляр.

Този директен 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 списък не е доказателство, че нищо не е създадено при оператора.