Skip to main content

​
Rejets 10DLC, re-vérification et cycle de vie post-approbation

Le guide d’enregistrement 10DLC se termine à « commencer l’envoi ». Ce guide couvre ce qui se passe ensuite — un rejet avec un code cryptique, un score de vérification qui plafonne votre débit, ou une campagne approuvée dont le plafond quotidien ne correspond plus à votre volume. Tout ce qui figure ici est un contrôle sur vos propres enregistrements ; les décisions des opérateurs et du registre restent les leurs.

​
D’où viennent les rejets

Un rejet est l’une de deux choses, et la différence décide de tout ce que vous ferez ensuite :
  • Les rejets du registre (TCR et les CSP qui le mandatent) se déclenchent pendant ou après la révision de l’enregistrement — le dossier lui-même est refusé. Ils apparaissent sous forme de statuts FAILED / REJECTED avec une chaîne rejectionReason, à trois endroits : dans l’assistant Settings > Compliance > 10DLC, une notification du tableau de bord lors de la transition terminale, et le champ rejectionReason de GET /api/v1/compliance/10dlc/campaigns/:id/status.
  • Les rejets des opérateurs (AT&T, T-Mobile) peuvent survenir après l’approbation TCR, dans la carte par opérateur mnoStatuses — un audit opérateur direct sur la marque, ou un opérateur qui conteste la décision au niveau CSP.
Certains codes sont émis avant que TCR ne décide quoi que ce soit : DUPLICATE-BRAND et l’échec du usecase en minuscules sont des signaux au moment de la soumission, pas des résultats de la phase de révision. Un rejet que l’assistant affiche immédiatement après la soumission relève généralement de cette catégorie. Deux rejets verrouillent l’enregistrement au lieu de demander une correction — BRAND-DCA-FAIL et DUPLICATE-BRAND renvoient une fiche de correction avec resubmit_allowed: false, ce qui signifie que l’identifiant de la marque est grillé et que la correction est un nouvel enregistrement, pas une modification.

​
Décoder un code de rejet brut en une fiche de correction

TCR et les CSP renvoient des codes comme 30883, 40016 et EIN-MISMATCH avec un motif d’une ligne en texte libre et aucune correction par champ. Le tableau de remédiation de Dépannage : campagne 10DLC rejetée couvre statiquement les cas courants ; l’endpoint du décodeur applique le même catalogue à n’importe quel code — y compris des formulations et des codes que le tableau ne liste pas. POST /api/v1/compliance/10dlc/decode-rejection Passez le code brut, plus le rejectionReason en texte libre lorsque vous l’avez — le texte libre lève l’ambiguïté des codes qui correspondent à plusieurs causes :
Réponse (200 OK) :
Lisez quatre champs de la fiche :
  • fix — l’étape corrective la plus probable, dans le même registre que la bannière de rejet de l’assistant.
  • resubmit_allowed — le verdict qui décide de votre prochain appel. true : modifiez la charge utile et re-soumettez la même marque ou campagne. false : l’enregistrement est verrouillé ; repartez sur un nouvel enregistrement.
  • category — un compartiment stable (eligibility, content, identity, throughput, format, dca, unknown) pour le regroupement dans votre propre interface.
  • field — l’étape de l’assistant à laquelle la correction s’applique (campaign.sample_message, brand.ein, …), afin de pouvoir relier l’opérateur au bon formulaire.
Le décodeur est un moteur de règles pur — il ne stocke rien, ne crée rien, et normalise le code pour vous : TCR-30883, Twilio Error 30883 et ein_mismatch se résolvent tous vers leurs entrées canoniques. Un code non reconnu renvoie une fiche de catégorie unknown dont le fix vous dirige vers la conformité Devotel, de sorte qu’une interface qui affiche la fiche ne montre jamais de panneau vide.
Exécutez le décodeur avant la remédiation. Lorsque le fix de la fiche réécrit un message d’exemple ou une description, passez la charge utile corrigée par le linter de pré-soumission avant de re-soumettre — il détecte le rejet de second ordre que la correction introduit souvent.

​
Exemple détaillé : « use case mismatch »

Une interrogation du statut de la campagne renvoie :
La chaîne de motif nomme la cause mais pas un code TCR. Le décodeur fonctionne avec l’un ou l’autre, alors passez ce que vous avez — le texte libre seul :
Réponse — la fiche 30898 :
resubmit_allowed: true indique une correction suivie d’une re-soumission. Re-soumettez maintenant la campagne corrigée contre la même marque — le même appel que le dépôt initial, re-déposé à l’identique :
Comptez les mêmes 1 à 5 jours ouvrés que pour le dépôt initial ; interrogez l’endpoint de statut ou surveillez la notification du tableau de bord.

​
Deuxième exemple détaillé : « SHAFT sample »

Il s’agit de la même boucle avec une fiche de catégorie contenu. Un motif comme "Sample 2 flagged: SHAFT sample" se décode en 30883 — violation de contenu — avec resubmit_allowed: true et field: "campaign.sample_message". Réécrivez l’exemple signalé pour déclarer la verticale déclarée et supprimer la formulation interdite, puis re-déposez la campagne à l’identique. L’intérêt de la boucle : un appel au décodeur, une soumission corrigée, et rien de tout cela ne dépend de la formulation que TCR a renvoyée.

​
Re-vérification ou re-soumission

Les corrections de contenu rejeté signifient une re-soumission. Un score de vérification faible est un blocage différent — aucune correction d’une charge utile de campagne ne le répare, et il plafonne chaque campagne de la marque, pas seulement celle en cours de révision. Le score détermine la limite, donc le remède est une re-vérification, pas une re-soumission. POST /api/v1/compliance/10dlc/brands/:id/revet
Réponse (200 OK) :
provider nomme le registraire qui porte la marque ; status est le statut actualisé de la marque une fois la re-vérification lancée. Avant de re-vérifier, complétez la fiche de la marque — EIN, dénomination sociale correspondant aux registres de l’IRS, site web, e-mail de support sur votre propre domaine — la re-vérification réévalue les mêmes informations, et une fiche inchangée renvoie un score inchangé. Le registraire limite le débit des re-vérifications (une fois immédiatement après l’enregistrement, puis environ une fois tous les trois mois), donc un appel limité renvoie 422 avec le texte d’attente du registraire — lisez-le, ne réessayez pas en boucle.

​
Planification du débit : ce que le score accorde

Deux endpoints transforment le score de vérification en limites sous lesquelles vous opérez. GET /api/v1/compliance/10dlc/brands/:id/vetting renvoie le résultat brut :
vettingScore: null signifie que l’EVP est encore en cours de traitement — affichez « En attente », pas 0. GET /api/v1/compliance/10dlc/brands/:id/throughput dérive les limites attribuées par les opérateurs à partir de ce score :
Réponse (200 OK) :
  • att.class — AT&T attribue une classe de débit par campagne, D→C→B→A (15 → 75 → 240 → 600 messages par minute), aux seuils de trust-score 0/25/50/75.
  • tmobile.tier — T-Mobile attribue un niveau de plafond quotidien par marque (2k / 10k / 40k / 200k / illimité) qui couvre chaque campagne et chaque numéro de la marque.
  • entity_type (paramètre de requête optionnel) — les marques de propriétaire unique sont plafonnées au niveau 2k et à la classe D quel que soit le score ; passez le type d’entité enregistré afin que la dérivation tienne compte du cas particulier.
  • sent_today (paramètre de requête optionnel) — segments de messages déjà envoyés dans la fenêtre glissante actuelle de 24 h. Lorsque vous le passez, consumption rapporte la marge avant la zone de filtrage silencieux : ok en dessous de 80 % du plafond, warning à 80 %, critical à 95 %, exceeded à 100 %.
Les deux paramètres de requête sont optionnels ; consumption vaut null tant que vous n’avez pas fourni sent_today.

​
Re-vérifier, ou accepter le niveau ?

Utilisez les seuils warning / critical comme signal. Lorsque votre volume courant se situe régulièrement dans la bande d’avertissement, planifiez une re-vérification — elle est limitée en débit, donc ne la consommez que sur un changement réel de trajectoire. Lorsque le plafond est le plafond quotidien plutôt que la classe, la contrainte est par marque : affecter davantage de numéros à la campagne ne la relève pas, tandis qu’une mise à niveau de SOLE_PROPRIETOR vers une fiche de marque complète le fait — il s’agit d’un changement de type d’entité, pas d’une re-vérification.

​
Re-soumission, re-vérification : ce que chacune coûte

TCR facture de nouveaux frais de vérification par re-soumission et par re-vérification (généralement quelques USD), et les opérateurs traitent chaque re-soumission comme une nouvelle révision — avec un calendrier indépendant de vos tentatives précédentes.

​
Voir aussi