Create a registration profile

Create the profile once

This request creates a local registration profile together with carrier identity and address records. Start with the current registration countries, number types and requirements. Requirements depend on the country and type of number you plan to register.

A successful create response is not regulatory approval or number activation. Save the document UUID, identity ID and address ID separately: they serve different purposes. This request changes account data and is not a validation-only operation.

Create request

Authenticate with your enabled MultiTEL API account and its allowed IP address. The examples use HTTP Basic credentials stored in environment variables. Check both the HTTP response and JSON status.code; an HTTP 200 response alone does not establish success. All example values are fictional.

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

The JSON is an illustrative Personal profile, not a ready-to-submit real identity. Replace its details and signature with the end-user information required by the selected registration rules. Form-encoded input is also supported.

Registration profile fields
Field	Required and format
`identity_type`	Required. Use the exact value Personal or Business; conditional validation depends on capitalization.
`first_name, last_name`	Required, each at most 64 characters. For a business, provide the representative details required by the selected country.
`phone_number`	Required numeric telephone value, at least eight characters. A digit-only international number including its country code is suitable for this validation; this is a contact number, not a number purchase.
`city, postal_code, address`	Required, each at most 64 characters.
`country`	Required address-country ISO code from the registration catalogue. The service resolves it to the carrier country record.
`signature`	Required signature data. The current portal supplies Base64 PNG image bytes without the data:image/png;base64, prefix. Obtain the end-user signature through your authorized workflow; a nonempty placeholder is not a meaningful signature.
`nationality`	Required for Personal, as a country ISO code. Do not substitute a country UUID.
`company_name, incorporation_country`	Required for Business. Company name is at most 64 characters; incorporation_country is a country ISO code.
`email`	Optional end-user contact email, at most 254 characters. Omitted or empty email does not inherit the base account email.
`company_reg_number, vat_id, id_number, personal_tax_id, birth_date, description`	Optional in this handler, but the selected country/carrier may require some of them. Supply the formats required for that registration. Direct API calls do not automatically apply every normalization performed by the portal.

This direct v3 handler requires address fields and creates an address. Do not assume the portal’s defer-address option is available through it.

Retain all three identifiers

The following shows selected response fields; the actual response also contains submitted profile information and signature data. Handle the complete response as private.

{
  "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 identifies the local profile. Use it with get_document. In documents and get_document responses, the same profile identifier is named id.
response.identity_id identifies the identity for later identity proofs and supporting documents.
response.address_id identifies the created address. Keep it separately; the local profile UUID is not an address ID. Later address-proof attachment compatibility for newly created profiles is still under review.

The two profile readback endpoints do not return identity_id or address_id, so retain the original successful create response. If it was lost, use the portal document view or contact support before creating a replacement.

Advanced: attach pre-uploaded proofs during creation

You may supply identity_encryptfiles and address_encryptfiles as arrays of IDs returned by create_encrypt_files. Upload using a proof type for the matching entity category, then submit before the roughly 20-minute file-reference expiry. The create handler checks the account, category and expiry of each supplied reference.

These fields have different names from the later attachment endpoint’s encrypted_file_ids. During creation, each file is sent as a separate proof request, even when several files share one proof type. For an identity proof that must contain several files together, use the later create_proof request with one array. Successful profile creation alone does not provide individual proof approval results.

If a later address proof is rejected for a newly created address, do not substitute the profile UUID or recreate the identity repeatedly. Stop and check the profile in the portal or with support. The address-proof readback/lookup path remains a review limitation.

Failures and partial creation

API code 400 covers field validation, carrier creation failures and local save failures. Validation errors may appear as field-keyed entries in response. Code 500 is used for an unavailable/invalid registration country, and code 404 for missing or expired pre-uploaded references. Read status.msg as well as the code.

The local profile and upstream carrier operations are not one atomic transaction. A failed request can leave upstream state even when no local profile is listed. No client idempotency key is exposed. After a timeout or uncertain failure, inspect existing profiles and contact support before repeating creation; an empty documents list is not proof that nothing was created upstream.