Upload registration proof files

Upload before attaching

Upload the files for one proof or supporting-document category, then attach the returned file IDs using create_proof or create_supporting_document. Uploading alone does not create an identity, an address, a proof or a completed number registration. Start with the current requirements and catalogue IDs.

Provide exactly one selector: proof_type_id for an identity/address proof, or supporting_template_id for a supporting document. Do not send both. Use IDs returned by the relevant MultiTEL catalogue; treat them as opaque identifiers.

Upload request

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" \
  --form-string "proof_type_id=$PROOF_TYPE_ID" \
  --form-string 'description=Identity proof' \
  --form 'files[0]=@./identity-proof.pdf' \
  https://api.multitel.net/v3/create_encrypt_files

Request fields
Field	Meaning
`files[0] … files[4]`	One to five uploaded files. Use multipart form data and let curl generate its Content-Type boundary. These fields contain file bytes, not URLs or JSON Base64.
`proof_type_id`	Required for a proof upload; use a returned proof-type ID. Omit supporting_template_id.
`supporting_template_id`	Required instead of proof_type_id for supporting files; use a returned template ID.
`description`	Optional caller-supplied description, at most 100 characters. A supporting upload can use the template name when the description is omitted.

File limits

At most five files and 20,000,000 bytes in total are accepted by this handler. This is a decimal byte limit, not 20 MiB. Infrastructure or MIME validation can impose additional limits.

The extension allowlist is pdf, png, jpg, jpeg, gif, tiff, bmp, doc, docx, xls, xlsx, txt, rtf and csv. An allowed extension does not establish that a file meets the selected registration requirement. In particular, tif is not in this allowlist.

Check every returned file

{
  "status": {
    "code": 200,
    "msg": "Encrypt file has been created successfully"
  },
  "response": {
    "entity_type": "identities",
    "document_category": "proof",
    "proof_type": "11111111111111111111111111111111",
    "ids": [
      {
        "id": "22222222222222222222222222222222",
        "name": "identity-proof.pdf",
        "expired_at": "2026-10-23 16:20:00"
      }
    ]
  }
}

Keep each response.ids[].id for the attachment request. name identifies the returned source filename. Use distinct filenames and compare the returned files with the expected set: a code 200 can represent a partially successful batch. Do not attach a set missing required files.

entity_type is identities or addresses for a proof, and supporting_documents for a supporting upload. document_category is proof or supporting. The generically named proof_type response field also carries a template reference for supporting uploads; keep your original supporting_template_id for the attachment.

Attach promptly

The service sets an expiry approximately 20 minutes after local upload storage. Attachment checks that the file belongs to the same account, is not marked expired, is still before its expiry, and has the correct entity category. expired_at has no timezone offset in this response; do not assume it is UTC. Attach promptly rather than scheduling work at the boundary.

The upload reference expiry is not a promise that all stored document copies are deleted at that time. The service encrypts files for the carrier upload and retains source bytes for the document workflow; do not treat this as client-only encryption or a no-retention service. Keep IDs, filenames and responses out of public logs.

Errors and retries

The current handler uses API code 404 when no document files are supplied, and code 500 for description validation, missing/conflicting selectors, invalid proof/template IDs, the file-count or aggregate-size limit, storage problems, or an unsuccessful upload. Read status.msg; invalid input is not consistently represented by code 400.

No client idempotency key is exposed here. If the response is lost, check the document workflow before repeating an upload; another request can create new file references. These examples have not been executed against customer identity documents.