Lire les exigences de campagne d’une marque

Gardez la marque et le cas d’usage ensemble

Utilisez l’ID de marque de votre compte et une valeur de cas d’usage renvoyée par la liste de qualification de cette même marque. Le flux de travail client vérifie la propriété avant la requête au fournisseur. Confirmez que le champ usecase de l’objet renvoyé correspond à la valeur sélectionnée. Une consultation pour une marque ou un cas d’usage n’établit pas les exigences d’une autre marque ou d’un autre cas d’usage.

Lire les exigences actuelles

Exigences utilisées par le formulaire de campagne actuel
Champ	Utilisation par le portail
minSubUsecases / maxSubUsecases	Nombre minimal et maximal de sous-cas d’usage pour cette sélection. Choisissez des valeurs dans le catalogue des sous-cas d’usage valides plutôt qu’un texte libre.
mnoMetadata	Exigences propres à chaque opérateur, indexées par ID d’opérateur. Utilisez les ID présents dans la réponse actuelle pour la sélection des opérateurs.
mnoSupport / qualify	Prise en charge et qualification par l’opérateur. Le portail exclut les opérateurs explicitement marqués false pour l’un ou l’autre de ces champs et exige au moins un opérateur sélectionné éligible.
minMsgSamples	Nombre d’exemples requis pour un opérateur. Le portail exige au moins un exemple non vide et respecte le minimum le plus élevé parmi les opérateurs sélectionnés éligibles.
reqSubscriberOptin / reqSubscriberOptout / reqSubscriberHelp	Déclarations d’abonné requises. Lorsqu’elle est requise, la déclaration correspondante doit être true. Les déclarations activées nécessitent également leurs champs de mots-clés et de message de réponse.
noEmbeddedLink / noEmbeddedPhone	Restrictions sur les liens ou numéros de téléphone intégrés. Le portail rejette une fonctionnalité déclarée si un opérateur sélectionné éligible l’interdit.

Appliquez ensemble les exigences des opérateurs sélectionnés

Les exigences des opérateurs peuvent différer. Lorsqu’aucune liste explicite d’opérateurs n’est fournie, le portail prend en compte toutes les métadonnées d’opérateur de la réponse ; une liste non vide limite les vérifications aux ID sélectionnés. N’utilisez pas uniquement le nombre d’exemples ou les déclarations du premier opérateur. Sélectionnez les opérateurs à partir de la réponse, vérifiez la prise en charge et la qualification, respectez le minimum d’exemples applicable le plus élevé et satisfaites les déclarations requises d’inscription (opt-in), de désinscription (opt-out) et d’aide sur l’ensemble de cette sélection. Le portail rejette les ID d’opérateur sélectionnés absents de la réponse actuelle et rejette une sélection sans opérateur éligible.

Les exigences décrivent ce qui doit être fourni ; elles ne prouvent pas que le processus de consentement du client ou le contenu de la campagne satisfait à ces exigences. Recueillez des exemples et des déclarations véridiques et représentatifs. N’activez pas automatiquement des déclarations pour faire passer un formulaire.

Préparer les exemples et les réponses aux abonnés

Le formulaire de campagne actuel utilise sample1 à sample5 pour les exemples de messages. Si les exigences ne peuvent pas être satisfaites dans le formulaire disponible, arrêtez-vous et résolvez la sélection avec le support. Pour une déclaration d’abonné activée, fournissez les mots-clés et le texte de réponse correspondants : optinKeywords/optinMessage, optoutKeywords/optoutMessage et helpKeywords/helpMessage. Gardez les exemples cohérents avec le cas d’usage choisi et les messages réellement envoyés aux clients.

Vérifier avant toute demande d’enregistrement

Actualisez les exigences lorsque la marque, le cas d’usage ou la sélection d’opérateurs change. Le portail revalide le cas d’usage sélectionné, le nombre de sous-cas d’usage, l’éligibilité des opérateurs, les exemples et les déclarations avant la création. Examinez séparément la tarification du compte et les conditions d’enregistrement. Ce GET n’enregistre ni n’approuve une campagne, ne la partage pas avec l’opérateur de messagerie et n’attribue pas de numéro de téléphone. La création et le provisionnement sont des opérations distinctes.

Gérer l’échec d’une consultation des exigences

Si la requête échoue, renvoie un JSON inattendu ou ne correspond pas au cas d’usage sélectionné, laissez le formulaire incomplet et laissez le client réessayer une fois l’erreur résolue. Ne remplacez pas des exigences indisponibles par un objet vide et ne supposez pas que l’absence de données signifie l’absence d’exigences. Respectez Retry-After et utilisez un délai d’attente progressif pour les limites de débit et les défaillances de disponibilité.

Requête

Utilisez un compte API activé via HTTPS depuis une adresse IP source autorisée. La route actuelle prend en charge la politique d’authentification du compte, y compris l’authentification Basic et les comptes API bearer activés. N’utilisez pas les identifiants du fournisseur.

GET avec l’ID de marque et la valeur de cas d’usage sélectionnée dans le chemin de l’URL. Aucun corps de requête n’est requis.

curl --fail-with-body --silent --show-error \
  --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/campaignBuilder/brand/$BRAND_ID/usecase/$USECASE"

Paramètres de chemin
Nom	Type	Requis	Description
`brand_id`	string	Oui	L’ID de marque du registre associé à votre compte MultiTEL authentifié. Utilisez l’ID de marque, et non un ID de ligne de base de données locale, un ID de campagne ou un numéro fiscal d’entreprise. Encodez-le comme un seul segment de chemin d’URL.
`usecase`	string	Oui	La valeur usecase lisible par machine sélectionnée dans la liste de qualification de cette même marque. Conservez sa casse ; n’envoyez pas de libellé d’affichage traduit. Encodez-la comme un seul segment de chemin d’URL.

Réponse

La route TCR actuelle renvoie directement le corps JSON du registre et conserve son statut HTTP. Elle n’ajoute pas l’enveloppe status/response héritée de la v3. L’exemple abrégé et fictif n’est pas un résultat de qualification réel. Vérifiez le statut HTTP et la forme JSON attendue avant de l’utiliser. Le portail attend un objet dont le champ usecase correspond au cas d’usage sélectionné. Les exigences des opérateurs se trouvent sous mnoMetadata, indexées par ID d’opérateur. L’ID d’opérateur et les exigences de l’exemple sont fictifs. D’autres champs du fournisseur peuvent être renvoyés.

Forme de réponse illustrative ; il ne s’agit ni de données de compte réelles ni d’un devis actuel.

{
  "usecase": "2FA",
  "minSubUsecases": 0,
  "maxSubUsecases": 0,
  "mnoMetadata": {
    "12345": {
      "mnoSupport": true,
      "qualify": true,
      "minMsgSamples": 1,
      "reqSubscriberOptin": true,
      "reqSubscriberOptout": true,
      "reqSubscriberHelp": true,
      "noEmbeddedLink": false,
      "noEmbeddedPhone": false
    }
  }
}

Erreurs

401 : L’authentification du compte a échoué. Vérifiez les identifiants API, l’état d’activation et les restrictions d’IP source applicables.
404 : La marque n’est pas associée au compte authentifié, ou le fournisseur ne trouve pas la marque ou la sélection demandée. Un refus de propriété local est renvoyé avant toute requête au fournisseur.
Autres erreurs du registre : Le statut HTTP et le corps en amont sont conservés. Un cas d’usage invalide ou indisponible n’est pas un ensemble d’exigences vide réussi.
429 : Limite de requêtes du compte ou du fournisseur partagé atteinte. Respectez Retry-After.
502/503 : Défaillance de disponibilité du transport, du fournisseur ou du limiteur de débit. Conservez le formulaire et réessayez avec un délai d’attente progressif.

Disponibilité et effets secondaires

Le GET examiné vérifie la propriété existante de la marque, contacte le registre et écrit des enregistrements d’audit de requête. Il ne crée ni marque ni campagne et ne facture aucun frais d’enregistrement.
Les métadonnées de frais du fournisseur ne constituent pas un devis de détail client MultiTEL. Le portail examine séparément la tarification du compte avant une demande d’enregistrement ultérieure.
La qualification et les exigences peuvent changer. Actualisez-les pour la marque et le cas d’usage sélectionnés avant la soumission. Une consultation réussie n’est ni une approbation de campagne, ni une attribution de numéro, ni une autorisation de commencer l’envoi de messages.