Soumettre une inscription à l’annuaire pour un numéro de téléphone

Soumettre une inscription à l’annuaire auprès de l’opérateur

Soumettez le nom et l’adresse à utiliser pour l’inscription à l’annuaire d’un numéro de téléphone admissible qui vous appartient dans MultiTEL. Il s’agit d’une mise à jour payante auprès de l’opérateur, et non d’une recherche du nom de l’appelant, d’une entrée dans un carnet d’adresses privé ou d’une mise à jour générale du champ LIDB dans l’inventaire du portail.

Ne soumettez que les informations dont le client a autorisé l’inscription à l’annuaire. Confirmez que l’opérateur prend en charge le numéro avant d’utiliser cette ancienne route. Le gestionnaire examiné ne vérifie ni l’admissibilité auprès du fournisseur ni le format international du numéro ; sa demande à l’opérateur suppose un numéro nord-américain et supprime le premier chiffre enregistré.

Exigences relatives au compte et au numéro

Utilisez un compte API activé via HTTPS, depuis une adresse IP source autorisée. Le numéro exact doit correspondre à une ligne non annulée de numéro acheté appartenant à ce compte. Utilisez tous les chiffres du numéro au format international figurant dans votre inventaire, par exemple le format avec l’indicatif de pays 1 pour un numéro nord-américain pris en charge. N’utilisez ni un identifiant de forfait tarifaire, ni un UUID de numéro, ni un numéro appartenant à un autre compte.

Requête POST avec données de formulaire

Définissez NUMBER sur le numéro qui vous appartient. Remplacez l’exemple fictif par les informations d’inscription autorisées. Cette route lit les champs de formulaire de la requête POST ; elle n’analyse pas de corps application/json.

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --data-urlencode "lastname=EXAMPLE" \
  --data-urlencode "firstname=EXAMPLE" \
  --data-urlencode "streetnum=1" \
  --data-urlencode "streetname=Example" \
  --data-urlencode "streetpredir=N" \
  --data-urlencode "streetpostdir=W" \
  --data-urlencode "city=Example City" \
  --data-urlencode "state=NY" \
  --data-urlencode "postalcode=10001" \
  "https://api.multitel.net/v3/directory/$NUMBER"

Les indications de direction et l’adresse de l’exemple sont fictives et ne constituent pas une adresse postale recommandée. N’ajoutez pas d’indication de direction fictive aux données réelles d’un client. Les contrôles des champs obligatoires de l’API sont sommaires : ils ne permettent pas d’établir qu’une adresse est valide ou acceptée par l’opérateur, et l’ancien site web appliquait des exigences de formulaire différentes.

L’implémentation peut émettre un avertissement de clé de tableau manquante lorsqu’une indication de direction facultative est absente ou vide. Si la réponse est mal formée ou si l’opérateur refuse l’adresse, conservez la référence de la demande et demandez à l’assistance de confirmer l’inscription plutôt que de soumettre à répétition des variantes d’adresse supposées correctes.

Facturation et nouvelles tentatives

Le gestionnaire examiné vérifie que le solde comprend au moins 10.00 unités de solde avant de contacter l’opérateur. Une fois que l’opérateur et la mise à jour locale du numéro ont tous deux signalé un succès, il déduit 10.00 du solde du compte et enregistre une transaction de mise en place de l’inscription à l’annuaire. Il s’agit des montants actuellement appliqués par l’implémentation, et non d’une nouvelle proposition tarifaire ; avant l’envoi, vérifiez dans les conditions de votre compte la devise de facturation applicable et le service pris en charge.

L’opération ne comporte ni clé d’idempotence, ni protection contre les commandes en double, ni transaction englobant l’envoi à l’opérateur, la mise à jour locale et la facturation. Une requête répétée qui réussit peut entraîner un nouvel envoi à l’opérateur et de nouveaux frais. Une expiration du délai d’attente ou une erreur de l’API ne prouve pas que l’opérateur a refusé la demande précédente : le fournisseur peut l’avoir acceptée avant l’échec d’une mise à jour locale.

Réponse

{
  "status": {
    "code": 200,
    "msg": "Success"
  },
  "response": ""
}

Dans la réponse normale de succès, une chaîne vide est affectée au champ response et aucun identifiant d’inscription ni détail de finalisation n’est renvoyé. Cela signifie que les parcours de traitement de l’opérateur et de mise à jour locale ont signalé un succès ; cela ne prouve ni la publication dans tous les annuaires externes, ni une propagation immédiate, ni l’affichage futur de l’identification de l’appelant.

Erreurs de l’ancien système

Consultez à la fois le statut HTTP et les champs JSON status.code/status.msg. L’authentification et les restrictions sur l’adresse IP source peuvent également empêcher l’obtention d’une réponse exploitable. N’utilisez pas GET ni des paramètres de requête pour demander une mise à jour au seul motif que l’ancien gestionnaire ne comporte pas de contrôle explicite de la méthode HTTP.

Vérifier avant de réessayer

1. Avant d’envoyer la demande, confirmez le numéro qui vous appartient, son admissibilité auprès de l’opérateur, les données d’inscription autorisées et les frais.
2. Soumettez la demande une seule fois et conservez le résultat côté compte sans exposer l’adresse du client dans des journaux publics ou des outils d’analyse.
3. Vérifiez l’inscription enregistrée et l’historique des transactions au moyen du parcours de gestion du compte pris en charge ou auprès de l’assistance. Respectez le délai de traitement confirmé par l’opérateur ; cette API ne définit aucun délai de propagation garanti.
4. Lorsque le résultat est incertain, demandez à l’assistance de rapprocher la commande auprès de l’opérateur et la facturation locale avant de réessayer. Répéter la demande ne constitue pas une vérification d’état idempotente.