Heg 'n identiteits- of adresbewys aan

Gebruik hierdie stap nadat die identiteit of adres bestaan en nadat die vereiste lêers daarvoor opgelaai is deur create_encrypt_files met die gekose bewystipe. Gebruik 'n huidige identifiseerder uit get_proof_types, wat by die vereiste en die entiteitskategorie pas.

Bewaar identity_id en address_id uit create_document; die profiel se UUID is anders. Versoenbaarheid met die latere aanhegting van adresbewyse vir nuut geskepte profiele word nog ondersoek. As die adres verwerp word, raadpleeg die portaal of ondersteuning voordat jy weer probeer.

Skep die bewys

Gebruik 'n geaktiveerde MultiTEL API-rekening en die IP-adres wat daarvoor toegelaat word. Die voorbeelde gebruik HTTP Basic-aanmeldbesonderhede uit omgewingsveranderlikes; volg die stawingskonvensies vir jou rekeningtipe. Stuur versoeke oor HTTPS. Gaan sowel die HTTP-antwoord as die volgende veld in die JSON na: status.code; toepassingsfoute kan saam met HTTP 200 ontvang word. Die voorbeelde hieronder is fiktief.

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

{
  "entity_type": "identities",
  "entity_id": "33333333333333333333333333333333",
  "proof_type_id": "11111111111111111111111111111111",
  "encrypted_file_ids": [
    "22222222222222222222222222222222"
  ]
}

Versoekvelde
Veld	Betekenis
`entity_type`	Gebruik identities of addresses. Kies die kategorie wat by sowel jou teiken as die opgelaaide lêers pas.
`entity_id`	Identifiseerder van die identiteit of adres wat aan jou rekening behoort. Gebruik die identifiseerder wat deur jou dokumentwerkvloei teruggestuur word; moenie dit met 'n telefoonnommer of die identifiseerder van 'n onverwante dokument vervang nie.
`proof_type_id`	Die identifiseerder van die gekose bewystipe. Maak seker dat dit met die oplaai en die vereiste ooreenstem.
`encrypted_file_ids`	'n Nieleë JSON-skikking van lêeridentifiseerders wat deur create_encrypt_files teruggestuur word. Lêers moet aan dieselfde rekening behoort, steeds geldig wees en by die entiteitskategorie pas. Dit is nie 'n lys van plaaslike lêerpaaie nie.

Vormdata word ook aanvaar met herhaalde encrypted_file_ids[]-velde. Gebruik verkieslik 'n werklike JSON-skikking of vormskikking; moenie 'n JSON-gekodeerde skikking as 'n gewone skalêre vormwaarde stuur nie.

Bewaar die bewys se identifiseerder

{
  "status": {
    "code": 200,
    "msg": "Proof created successfully."
  },
  "response": {
    "id": "44444444444444444444444444444444",
    "entity_type": "identities",
    "entity_id": "33333333333333333333333333333333",
    "proof_type_id": "11111111111111111111111111111111",
    "proof_type_name": "Example identity proof"
  }
}

'n Suksesvolle antwoord bevestig dat die koppeling van die bewys geskep is. Dit bevestig nie goedkeuring van die identiteit/adres, validering van alle landvereistes of aktivering van 'n telefoonnommer nie.

Foute en vervalde opgelaaide lêers

API-kode 500 word gebruik vir ontbrekende vereiste invoer, diensverskafferfoute en 'n ongeldige antwoord van die diensverskaffer. Kode 404 word gebruik wanneer die teiken nie aan die huidige rekening gekoppel is nie, die bewystipe ongeldig is, 'n opgelaaide lêer nie vir hierdie rekening/kategorie gevind kan word nie of verval het, of daar geen bruikbare lêeridentifiseerders oorbly nie. Lees status.msg saam met die kode.

Laai 'n vereiste lêer wat verval het weer op met die korrekte bewyskategorie voordat jy dit aanheg. As enige verskafte lêer ongeldig is, stop hierdie hanteerder voordat die versoek om die bewys te skep gestuur word. Geen idempotensiesleutel word beskikbaar gestel nie: gaan ná 'n tydverstryking die bestaande dokument in die portaal na voordat jy die aanhegting herhaal.