Créer un profil d'enregistrement

Créer le profil une seule fois

Cette requête crée un profil d'enregistrement local ainsi que des enregistrements d'identité et d'adresse chez l'opérateur. Commencez par consulter la liste actuelle des pays d'enregistrement, types de numéros et exigences. Les exigences dépendent du pays et du type de numéro que vous prévoyez d'enregistrer.

Une réponse de création réussie ne constitue ni une approbation réglementaire ni une activation de numéro. Enregistrez séparément l'UUID du document, l'ID d'identité et l'ID d'adresse : ils servent à des fins différentes. Cette requête modifie les données du compte et n'est pas une opération de simple validation.

Requête de création

Authentifiez-vous avec votre compte API MultiTEL activé et son adresse IP autorisée. Les exemples utilisent des identifiants HTTP Basic stockés dans des variables d'environnement. Vérifiez à la fois la réponse HTTP et le champ JSON status.code; une réponse HTTP 200 à elle seule ne prouve pas le succès. Toutes les valeurs d'exemple sont fictives.

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

Le JSON est un profil Personal donné à titre d'illustration, et non une identité réelle prête à soumettre. Remplacez ses détails et sa signature par les informations de l'utilisateur final exigées par les règles d'enregistrement sélectionnées. L'entrée encodée en formulaire est également prise en charge.

Ce gestionnaire v3 direct exige les champs d'adresse et crée une adresse. Ne présumez pas que l'option de report d'adresse du portail est disponible par son intermédiaire.

Conserver les trois identifiants

Ce qui suit présente une sélection de champs de réponse ; la réponse réelle contient également les informations de profil soumises et les données de signature. Traitez la réponse complète comme confidentielle.

{
  "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 identifie le profil local. Utilisez-le avec get_document. Dans les réponses de documents et de get_document, le même identifiant de profil porte le nom id.
• response.identity_id identifie l'identité pour l'envoi ultérieur de preuves d'identité et de documents justificatifs.
• response.address_id identifie l'adresse créée. Conservez-le séparément ; l'UUID du profil local n'est pas un ID d'adresse. La compatibilité de l'ajout ultérieur de preuves d'adresse pour les profils nouvellement créés est encore en cours d'examen.

Les deux points de terminaison de relecture du profil ne renvoient ni identity_id ni address_id ; conservez donc la réponse de création réussie d'origine. Si elle a été perdue, utilisez la vue des documents du portail ou contactez l'assistance avant de créer un profil de remplacement.

Avancé : joindre des preuves déjà téléversées lors de la création

Vous pouvez fournir identity_encryptfiles et address_encryptfiles sous forme de tableaux d'ID renvoyés par create_encrypt_files. Téléversez avec un type de preuve correspondant à la catégorie d'entité concernée, puis soumettez avant l'expiration de la référence de fichier, d'environ 20 minutes. Le gestionnaire de création vérifie le compte, la catégorie et l'expiration de chaque référence fournie.

Ces champs portent des noms différents du champ encrypted_file_ids du point de terminaison d'ajout ultérieur. Lors de la création, chaque fichier est envoyé comme une demande de preuve distincte, même lorsque plusieurs fichiers partagent un même type de preuve. Pour une preuve d'identité qui doit regrouper plusieurs fichiers, utilisez la requête create_proof ultérieure avec un seul tableau. La réussite de la création du profil ne fournit pas à elle seule les résultats d'approbation de chaque preuve.

Si une preuve d'adresse ultérieure est rejetée pour une adresse nouvellement créée, ne substituez pas l'UUID du profil et ne recréez pas l'identité à répétition. Arrêtez-vous et vérifiez le profil dans le portail ou auprès de l'assistance. Le chemin de relecture et de consultation des preuves d'adresse reste une limitation de l'examen.

Échecs et création partielle

Le code API 400 couvre la validation des champs, les échecs de création chez l'opérateur et les échecs d'enregistrement local. Les erreurs de validation peuvent apparaître sous forme d'entrées indexées par champ dans response. Le code 500 est utilisé pour un pays d'enregistrement indisponible ou invalide, et le code 404 pour des références téléversées au préalable manquantes ou expirées. Lisez status.msg en plus du code.

Le profil local et les opérations en amont chez l'opérateur ne forment pas une transaction atomique unique. Une requête échouée peut laisser un état en amont même lorsqu'aucun profil local n'est répertorié. Aucune clé d'idempotence côté client n'est exposée. Après un délai d'attente dépassé ou un échec incertain, examinez les profils existants et contactez l'assistance avant de répéter la création ; une liste documents vide ne prouve pas que rien n'a été créé en amont.