Attach an identity or address proof

Use this step after the identity or address exists and after uploading its required files through create_encrypt_files with the selected proof type. Use a current ID from get_proof_types, matching the requirement and entity category.

Retain identity_id and address_id from create_document; the profile UUID is different. Later address-proof attachment compatibility for newly created profiles is still under review. If the address is rejected, check the portal or support before retrying.

Create the proof

Use an enabled MultiTEL API account and its permitted IP address. The examples use HTTP Basic credentials from environment variables; follow the authentication conventions for your account type. Send requests over HTTPS. Check both the HTTP response and the JSON status.code; application errors can arrive with HTTP 200. Examples below are fictional.

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"
  ]
}

Request fields
Field	Meaning
`entity_type`	Use identities or addresses. Choose the category matching both your target and the uploaded files.
`entity_id`	ID of the identity or address owned by your account. Use the identifier returned by your document workflow; do not substitute a phone number or an unrelated document ID.
`proof_type_id`	The selected proof-type ID. Keep it consistent with the upload and the requirement.
`encrypted_file_ids`	Nonempty JSON array of file IDs returned by create_encrypt_files. Files must belong to the same account, remain unexpired and match the entity category. This is not a list of local file paths.

Form data is also accepted with repeated encrypted_file_ids[] fields. Prefer a real JSON array or form array; do not send a JSON-encoded array as an ordinary scalar form value.

Keep the proof ID

{
  "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"
  }
}

A successful response confirms creation of the proof association. It does not confirm approval of the identity/address, validation of all country requirements, or activation of a telephone number.

Errors and expired uploads

API code 500 is used for missing required inputs, carrier failures and an invalid carrier response. Code 404 is used when the target is not associated with the current account, the proof type is invalid, an uploaded file cannot be found for this account/category or has expired, or no usable file IDs remain. Read status.msg along with the code.

Re-upload an expired required file using the correct proof category before attaching it. If any supplied file is invalid, this handler stops before sending the proof creation request. No idempotency key is exposed: after a timeout, check the existing document in the portal before repeating the attachment.