Skip to main content

​
Rechazos 10DLC, re-verificación y el ciclo de vida posterior a la aprobación

La guía de registro 10DLC termina en “empiece a enviar”. Esta guía cubre lo que viene después — un rechazo con un código críptico, una puntuación de verificación que limita su rendimiento, o una campaña aprobada cuyo tope diario ya no se ajusta a su volumen. Todo lo que sigue es un control sobre sus propios registros; las decisiones del operador y del registro siguen siendo suyas.

​
De dónde vienen los rechazos

Un rechazo es una de dos cosas, y la diferencia decide todo lo que usted hace después:
  • Rechazos del registro (TCR y los CSP que lo proxy) se disparan durante o después de la revisión de registro — la solicitud misma es rechazada. Estos aparecen como registros de estado FAILED / REJECTED con una cadena rejectionReason, en tres lugares: el asistente de Settings > Compliance > 10DLC, una notificación del panel sobre la transición terminal, y el campo rejectionReason de GET /api/v1/compliance/10dlc/campaigns/:id/status.
  • Rechazos del operador (AT&T, T-Mobile) pueden llegar tras la aprobación de TCR, dentro del mapa por operador mnoStatuses — una auditoría directa del operador sobre la marca, o un operador que no está de acuerdo con la decisión a nivel CSP.
Algunos códigos se emiten antes de que TCR decida nada: DUPLICATE-BRAND y el fallo de usecase en minúsculas son señales en el momento del envío, no resultados de la fase de revisión. Un rechazo que el asistente muestra inmediatamente después de que usted envíe suele caer en esta clase. Dos rechazos bloquean el registro en lugar de solicitar una enmienda — BRAND-DCA-FAIL y DUPLICATE-BRAND devuelven una tarjeta de corrección con resubmit_allowed: false, lo que significa que el identificador de marca está quemado y la corrección es un registro nuevo, no una edición.

​
Decodifique un código crudo de rechazo en una tarjeta de corrección

TCR y los CSP devuelven códigos como 30883, 40016 y EIN-MISMATCH con un motivo de texto libre de una línea y sin corrección por campo. La tabla de remediación en Troubleshooting: 10DLC campaign rejected cubre los casos comunes de forma estática; el endpoint decodificador aplica el mismo catálogo a cualquier código — incluidas las redacciones y códigos que la tabla no enumera. POST /api/v1/compliance/10dlc/decode-rejection Pase el code crudo, más el rejectionReason de texto libre cuando lo tenga — el texto libre desambigua códigos que se asignan a más de una causa:
Respuesta (200 OK):
Lea cuatro campos de la tarjeta:
  • fix — el único paso correctivo de mayor probabilidad, en el mismo registro que usa el banner de rechazo del asistente.
  • resubmit_allowed — el veredicto que decide su próxima llamada. true: corrija la carga útil y vuelva a enviar la misma marca o campaña. false: el registro está bloqueado; inicie un registro nuevo.
  • category — un cubo estable (eligibility, content, identity, throughput, format, dca, unknown) para agrupar en su propia UI.
  • field — el paso del asistente al que se aplica la corrección (campaign.sample_message, brand.ein, …), de modo que puede enlazar al operador de vuelta al formulario correcto.
El decodificador es un motor de reglas puro — no almacena nada, no crea nada, y normaliza el código por usted: TCR-30883, Twilio Error 30883 y ein_mismatch se resuelven a sus entradas canónicas. Un código no reconocido devuelve una tarjeta de categoría unknown cuyo fix le dirige a cumplimiento de Devotel, de modo que una UI que renderiza la tarjeta nunca muestra un panel vacío.
Ejecute el decodificador antes de ejecutar la remediación. Cuando el fix de la tarjeta reescribe un mensaje de muestra o una descripción, pase la carga útil corregida por el linter de preflight antes de reenviar — detecta el rechazo de segundo orden que la corrección suele introducir.

​
Ejemplo resuelto: ‘use case mismatch’

Una consulta de estado de campaña devuelve:
La cadena de motivo nombra la causa pero no un código de TCR. El decodificador trabaja con uno o con el otro, así que pase lo que tenga — solo el texto libre:
Respuesta — la tarjeta 30898:
resubmit_allowed: true dice corregir-y-reenviar. Ahora vuelva a enviar la campaña corregida sobre la misma marca — la misma llamada que la solicitud inicial, reenviada tal cual:
Espere los mismos 1–5 días hábiles que la solicitud inicial; sondee el endpoint de estado o vigile la notificación del panel.

​
Un segundo ejemplo resuelto: ‘SHAFT sample’

Es el mismo bucle con una tarjeta de clase de contenido. Un motivo como "Sample 2 flagged: SHAFT sample" se decodifica a 30883 — violación de contenido — con resubmit_allowed: true y field: "campaign.sample_message". Reescriba la muestra marcada para declarar el vertical declarado y elimine el texto prohibido, y luego reenvíe la campaña tal cual. El sentido del bucle: una llamada al decodificador, un envío corregido, y nada de ello depende de qué redacción TCR haya devuelto.

​
Re-verificación frente a reenvío

Las correcciones de contenido rechazado significan reenvío. Una puntuación de verificación baja es un bloqueo diferente — ninguna cantidad de corrección a una carga útil de campaña lo repara, y limita cada campaña de la marca, no solo la que está en revisión. La puntuación decide el límite, así que el remedio es una re-verificación, no un reenvío. POST /api/v1/compliance/10dlc/brands/:id/revet
Respuesta (200 OK):
provider nombra qué registrador porta la marca; status es el estado actualizado de la marca una vez que la re-verificación arranca. Antes de re-verificar, complete el registro de la marca — EIN, nombre legal que coincida con los registros del IRS, sitio web, correo de soporte en su propio dominio — la re-verificación vuelve a puntuar la misma información, y un registro sin cambios devuelve una puntuación sin cambios. El registrador limita la tasa de re-verificaciones (una inmediatamente tras el registro, luego una cada tres meses aproximadamente), de modo que una llamada limitada por tasa devuelve 422 con el texto de espera del registrador — léalo, no reintente en un bucle.

​
Planificación de rendimiento: lo que la puntuación concede

Dos endpoints convierten la puntuación de verificación en los límites bajo los que usted opera. GET /api/v1/compliance/10dlc/brands/:id/vetting devuelve el resultado crudo:
vettingScore: null significa que el EVP todavía está procesando — muestre “Pending”, no 0. GET /api/v1/compliance/10dlc/brands/:id/throughput deriva los límites asignados por el operador a partir de esa puntuación:
Respuesta (200 OK):
  • att.class — AT&T asigna una clase de rendimiento por campaña, D→C→B→A (15 → 75 → 240 → 600 mensajes por minuto), en umbrales de puntuación de confianza 0/25/50/75.
  • tmobile.tier — T-Mobile asigna un nivel de tope diario por marca (2k / 10k / 40k / 200k / ilimitado) que cubre cada campaña y número de la marca.
  • entity_type (parámetro de consulta opcional) — las marcas de propietario único están limitadas al nivel 2k y a la Clase D independientemente de la puntuación; pase el tipo de entidad registrado para que la derivación vea el caso especial.
  • sent_today (parámetro de consulta opcional) — partes de mensaje ya enviadas en la ventana móvil de 24 h actual. Cuando lo pasa, consumption reporta el margen antes de la zona de filtrado silencioso: ok por debajo del 80 % del tope, warning al 80 %, critical al 95 %, exceeded al 100 %.
Ambos parámetros de consulta son opcionales; consumption es null hasta que proporcione sent_today.

​
¿Re-verificar, o aceptar el nivel?

Use los umbrales warning / critical como la señal. Cuando su volumen en primer plano aterriza de forma consistente en la banda de advertencia, planifique una re-verificación — está limitada por tasa, así que quémela solo con un cambio de trayectoria real. Cuando el techo es el tope diario en lugar de la clase, la restricción es por marca: asignar más números a la campaña no la eleva, y una actualización de SOLE_PROPRIETOR a un registro de marca completo sí lo hace — eso es un cambio de tipo de entidad, no una re-verificación.

​
Reenvío, re-verificación: qué cuesta cada uno

TCR cobra una nueva tarifa de verificación por reenvío y por re-verificación (normalmente unos pocos USD), y los operadores tratan cada reenvío como una revisión nueva — con temporización independiente de sus intentos anteriores.

​
Véase también