Un SMS aceptado aún puede fallar por un número inválido, un dispositivo inaccesible o un problema de red. El registro del mensaje, el evento de entrega y el error devuelto ayudan a distinguir esos resultados del filtrado.
¿Cómo investigo un filtro sospechado?
Comparas el registro del mensaje con sus eventos de SMS. El evento describe el resultado; el error y los detalles del proveedor ayudan a explicarlo.
| Evento | Qué te indica el evento |
|---|---|
sms.rejected | El procesamiento o un proveedor posterior rechazó el mensaje aceptado. |
sms.failed | Se reportó un fallo permanente. |
sms.undelivered | Se reportó un fallo recuperable, como un suscriptor inaccesible o un problema de red. |
sms.expired | El proveedor reportó expiración. |
Ningún evento por sí solo demuestra filtrado. En el mapeo de acuses de recibo de Bird, un motivo del proveedor de carrier_rejected se convierte en content_rejected. Un motivo no mapeado se convierte en unknown, que requiere investigación y puede tener una causa no relacionada. El estado de un acuse de recibo determina el evento de forma independiente a su motivo, así que un rechazo del operador puede acompañar distintos eventos de fallo.
El catálogo de errores define blocked_by_carrier y sender_unregistered. Su ausencia no descarta el filtrado: Bird convierte carrier_rejected en content_rejected y las causas sin correspondencia en unknown. Comprueba el código devuelto, conserva los valores desconocidos y guarda los detalles del proveedor.
¿Qué detalles debo guardar?
Conserva el ID del mensaje, el remitente, el destino, la hora de envío, el tipo de evento, el error.code normalizado, la descripción y carrier_error_code. Agrupa los fallos por destino, remitente y tipo de mensaje; un fallo aislado te da menos evidencia que un cambio que afecta a un grupo consistente de envíos.
El código normalizado es el campo estable para la lógica de tu aplicación. La descripción es texto diagnóstico, así que no la interpretes como un contrato fijo. carrier_error_code contiene el código más detallado del proveedor de envío cuando se proporciona; no se garantiza que sea el código propio del operador móvil. Puede estar vacío cuando el proveedor no proporciona ninguno o cuando el fallo ocurre antes de la entrega al proveedor.
Por ejemplo, content_rejected te orienta hacia el rechazo reportado, invalid_destination hacia el número del destinatario y provider_unavailable hacia el resultado de red o capacidad. unknown deja la causa sin resolver. Comparte el ID del mensaje y el código de proveedor disponible con soporte cuando esos detalles no expliquen el fallo.
¿Registrar mi remitente previene el filtrado?
El registro satisface el programa de remitente aplicable; no garantiza la entrega. El remitente también debe ser elegible para el destino, y el mensaje y el tráfico deben cumplir los requisitos correspondientes.
Para mensajería A2P en EE. UU. con números locales, verifica el registro 10DLC completo: marca, campaña y vinculación de número. Una marca o campaña aprobada no vincula por sí sola cada número que posees. Los programas de números gratuitos y códigos cortos tienen requisitos diferentes. Otros destinos pueden requerir registro de nombre de remitente.
Usa destinos de SMS para planificar la elección de remitente, luego confirma los requisitos aplicables y el estado de registro de tu espacio de trabajo antes del lanzamiento. Una guía de país es una referencia puntual, no una prueba de que tu remitente está aprobado.
¿Qué debo hacer con un fallo de opt-out?
Preserva la preferencia. Un envío a un par remitente-destinatario suprimido por Bird se rechaza en API con E12077; ese rechazo no crea ningún mensaje ni evento de mensaje. Un reporte posterior de recipient_opted_out es diferente: es un resultado para un mensaje aceptado y hace que Bird registre una supresión para el par.
Las palabras clave de baja admitidas pueden crear bloqueos por pareja remitente-destinatario. Estos eventos no representan todas las preferencias del espacio de trabajo ni todas las solicitudes recibidas por atención al cliente. Incluye esas preferencias más amplias en la selección de tu audiencia. No cambies de remitente para eludir una baja.
¿Qué debo verificar antes de reintentar?
- Preparación del remitente. Confirma el tipo de remitente, el registro y el acceso al destino requeridos para este tráfico.
- Permiso y relevancia. Confirma que la persona aceptó este propósito y no ha retirado ese permiso.
- Contenido y enlaces. Identifica la empresa con claridad, usa enlaces apropiados y revisa los requisitos de contenido del destino. Cambiar solo un enlace no puede establecer la elegibilidad de entrega.
- Tráfico y temporización. Compara los envíos fallidos con tu patrón normal, el encolamiento y los límites de la ruta. Reenviar repetidamente el mismo contenido rechazado puede añadir costo sin corregir la causa.
- El fallo reportado. Investiga los rechazos permanentes antes de enviar de nuevo. Para una respuesta ambigua de API, reutiliza la clave de idempotencia original dentro de su ventana de repetición; no conviertas la incertidumbre en una segunda solicitud automáticamente.
El enrutamiento de SMS aplica controles de destino antes de entregar el mensaje al operador. Una integración de SMS sigue cada solicitud aceptada mediante su registro de mensaje y sus eventos de entrega.
En resumen
Un fallo de entrega es un punto de partida para investigar.
El evento, el error normalizado y los detalles del proveedor describen el fallo. Una causa desconocida no demuestra filtrado por parte del operador.
El registro es un requisito, no una garantía de entrega.
Revisa el remitente, el destino, el contenido, el permiso y el patrón de tráfico antes de decidir qué cambiar.
Un opt-out es una preferencia que debes preservar.
Distingue un rechazo de API para un par suprimido de un reporte de opt-out posterior en la cadena, y respeta el alcance completo de la solicitud de la persona.
Conserva la evidencia junto con el mensaje.
Guarda el ID del mensaje, el destino, el remitente, la hora, el evento y los detalles de error para que puedas investigar un patrón o abrir un caso de soporte útil.