Téléversez les fichiers avant de les joindre
Téléversez les fichiers d’une seule catégorie de justificatif ou de document complémentaire, puis joignez les identifiants de fichiers renvoyés à l’aide de create_proof ou create_supporting_document. Le téléversement seul ne crée ni identité, ni adresse, ni justificatif et ne finalise pas l’enregistrement d’un numéro. Commencez par consulter les exigences en vigueur et les identifiants du catalogue.
Fournissez exactement un sélecteur : proof_type_id pour un justificatif d’identité ou de domicile, ou supporting_template_id pour un document complémentaire. N’envoyez pas les deux. Utilisez les identifiants renvoyés par le catalogue MultiTEL correspondant ; considérez-les comme des identifiants opaques.
Requête de téléversement
Utilisez un compte API MultiTEL activé et l’adresse IP autorisée pour ce compte. Les exemples utilisent des identifiants d’authentification HTTP Basic provenant de variables d’environnement ; suivez les conventions d’authentification propres à votre type de compte. Envoyez les requêtes via HTTPS. Vérifiez à la fois la réponse HTTP et le champ JSON status.code ; des erreurs applicatives peuvent être renvoyées avec un statut HTTP 200. Les exemples ci-dessous sont fictifs.
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| Champ | Signification |
|---|---|
files[0] … files[4] | De un à cinq fichiers à téléverser. Utilisez des données de formulaire multipart et laissez curl générer le délimiteur de Content-Type. Ces champs contiennent les octets des fichiers, et non des URL ou du contenu Base64 dans du JSON. |
proof_type_id | Obligatoire pour téléverser un justificatif ; utilisez un identifiant de type de justificatif renvoyé. Omettez supporting_template_id. |
supporting_template_id | Obligatoire à la place de proof_type_id pour les fichiers complémentaires ; utilisez un identifiant renvoyé correspondant à l’identifiant de modèle. |
description | Description facultative fournie par l’appelant, de 100 caractères au maximum. Pour un téléversement de document complémentaire, le nom du modèle peut être utilisé si la description est omise. |
Limites des fichiers
Ce gestionnaire accepte au maximum cinq fichiers et un total de 20,000,000 octets. Cette limite est exprimée en octets décimaux ; elle ne correspond pas à 20 MiB. L’infrastructure ou la validation MIME peuvent imposer des limites supplémentaires.
Les extensions autorisées sont pdf, png, jpg, jpeg, gif, tiff, bmp, doc, docx, xls, xlsx, txt, rtf et csv. Une extension autorisée ne garantit pas qu’un fichier satisfait à l’exigence d’enregistrement sélectionnée. En particulier, tif ne figure pas dans cette liste d’extensions autorisées.
Vérifiez chaque fichier renvoyé
{
"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"
}
]
}
}Conservez chaque response.ids[].id pour la requête de rattachement. name indique le nom du fichier source renvoyé. Utilisez des noms de fichiers distincts et comparez les fichiers renvoyés à l’ensemble attendu : un code 200 peut correspondre à un lot partiellement réussi. Ne joignez pas un ensemble auquel il manque des fichiers obligatoires.
entity_type vaut identities ou addresses pour un justificatif, et supporting_documents pour un téléversement de document complémentaire. document_category vaut proof ou supporting. Le champ de réponse au nom générique proof_type contient également une référence de modèle pour les téléversements de documents complémentaires ; conservez votre supporting_template_id d’origine pour le rattachement.
Joignez les fichiers rapidement
Le service fixe une expiration environ 20 minutes après le stockage local du fichier téléversé. Lors du rattachement, il vérifie que le fichier appartient au même compte, n’est pas marqué comme expiré, n’a pas encore atteint sa date d’expiration et relève de la bonne catégorie d’entité. expired_at ne comporte aucun décalage de fuseau horaire dans cette réponse ; ne supposez pas qu’il s’agit de l’heure UTC. Joignez les fichiers rapidement plutôt que de programmer l’opération à la limite d’expiration.
L’expiration de la référence de téléversement ne garantit pas la suppression de toutes les copies stockées du document à cet instant. Le service chiffre les fichiers pour leur téléversement auprès de l’opérateur et conserve les octets source pour le processus documentaire ; ne le considérez ni comme un chiffrement effectué uniquement côté client, ni comme un service sans conservation des données. N’inscrivez pas les identifiants, les noms de fichiers ou les réponses dans des journaux publics.
Erreurs et nouvelles tentatives
Le gestionnaire actuel utilise le code API 404 lorsqu’aucun fichier de document n’est fourni, et le code 500 pour les erreurs de validation de la description, les sélecteurs absents ou incompatibles, les identifiants de justificatif ou de modèle non valides, le dépassement des limites de nombre de fichiers ou de taille totale, les problèmes de stockage ou un téléversement infructueux. Consultez status.msg ; les données d’entrée non valides ne sont pas systématiquement signalées par le code 400.
Aucune clé d’idempotence côté client n’est proposée ici. Si la réponse est perdue, vérifiez le processus documentaire avant de renouveler le téléversement ; une autre requête peut créer de nouvelles références de fichiers. Ces exemples n’ont pas été exécutés avec des documents d’identité de clients.