SMS

¿Cuál es la diferencia entre SMS unidireccional y bidireccional?

SMS unidireccional envía mensajes sin aceptar respuestas; SMS bidireccional también recibe mensajes del destinatario.

La forma de un remitente determina si las respuestas tienen una dirección. Un número SMS elegible puede recibir un mensaje; un nombre alfanumérico no.

La distinción suena como una función que activas. En realidad se parece más a una propiedad física de aquello desde lo que enviaste, con una política por país superpuesta.

¿Qué hace que un remitente sea unidireccional?

No tener una dirección detrás.

Una respuesta es un mensaje dirigido a quien envió el último. Si el remitente era un número, esa dirección existe y el teléfono puede usarla. Si el remitente era un sender ID alfanumérico, no hay número al que dirigirse, y el propio modelo de Bird registra esa ausencia directamente: el código de país de ese remitente es null, descrito como "the country of the number this sender sends from", y no lleva number id porque "an alphanumeric sender has no number behind it".

Así que el primer corte es estructural. Los códigos largos, los números gratuitos y los códigos cortos pueden recibir. Un remitente alfanumérico no, en ningún país ni bajo ningún registro.

El segundo corte es por país. Cada tipo de remitente que un destino soporta reporta un direction de one_way o two_way, así que un tipo de número que acepta respuestas en un destino puede ser solo de envío en otro. La política de SMS del país también tiene su propio flag is_two_way_supported. Ambos son valores por destino que cambian, así que se publican en destinos de SMS en lugar de listarse aquí; cada página de destino indica si la mensajería bidireccional está soportada.

¿Cómo llega una respuesta a mi aplicación?

Como un evento, enviado a ti, con el mensaje ya almacenado.

Cuando un suscriptor envía un mensaje a uno de tus números, Bird almacena el mensaje junto a tus envíos y emite sms.received. El payload lleva el cuerpo, el desglose de segmentos, ambos números y el operador cuando el carrier lo reporta. No hay nada que sondear.

Algo ocurre antes de que ese evento te llegue, y cambia lo que debes hacer en el handler. Bird evalúa la respuesta contra las reglas de palabras clave de ese número primero. Una palabra clave de stop reconocida registra una supresión de remitente-y-suscriptor y envía la confirmación de exclusión, y aun así emite sms.received. Así que un mensaje entrante que era una exclusión llega a tu endpoint con el mismo aspecto que cualquier otro mensaje entrante, ya procesado.

La consecuencia para tu código: no trates cada sms.received como un turno de conversación. Algunos son exclusiones que Bird ya procesó, y reenviar cualquier cosa en respuesta a uno es el error que ese patrón invita a cometer. Qué es una palabra clave STOP cubre qué palabras clave se reconocen, dónde, y qué pasa en un país fuera del catálogo.

¿Desde qué remitente respondo?

Usa el número al que la persona escribió mientras siga siendo elegible, para que la respuesta sea reconocible. Tu aplicación envía a través del endpoint público de SMS con las verificaciones habituales de remitente, destino y destinatario.

Las confirmaciones internas de palabras clave de Bird tienen un contexto de respuesta interno separado. Ese contexto no es un campo que tu solicitud de API pueda reclamar. No permite una respuesta conversacional ni que una campaña eluda el registro, el acceso al destino o la exclusión de una persona.

Antes de responder, clasifica el mensaje entrante. Una solicitud de STOP o ayuda debe seguir su flujo de gestión correspondiente, en lugar de disparar una respuesta automatizada sin relación. Requisitos de remitente y gestión de palabras clave describen las verificaciones pertinentes.

¿Qué me cuesta la bidireccional que la unidireccional no?

Cuatro cosas, ninguna opcional una vez que aceptas respuestas.

  1. Un endpoint que verifique y procese eventos de forma fiable. Lo entrante se envía por push; contempla reintentos y entregas duplicadas. Gestión de webhooks cubre firmas, reintentos y reproducción. La identidad del evento está en el header webhook-id, fuera del cuerpo. Usa su valor como tu clave de deduplicación.
  2. Un número en cada destino que lo necesite. Un remitente alfanumérico no puede formar parte de un programa bidireccional, así que una campaña que los mezcle necesita un plan para los destinos donde solo el nombre está disponible. Ir por la vía unidireccional tampoco es una forma de eludir la obligación: un régimen que otorga derecho a la exclusión puede exigir que un remitente unidireccional revele que las respuestas no funcionan y ofrezca otra vía, como detalla qué es la TCPA.
  3. Gestionar los mensajes que no diseñaste. La gente responde a las notificaciones. Algunas de esas respuestas son preguntas, otras son exclusiones y otras no son ninguna de las dos.
  4. Leer el lado entrante de tus propios números. Bird reporta el volumen entrante por separado del saliente, así que un programa bidireccional tiene un segundo conjunto de números que vigilar.

Si nada de eso aplica, la unidireccional no es una rebaja. Es el compromiso más pequeño, y un remitente alfanumérico te da un nombre reconocible en el campo de remitente en los destinos que lo soportan. Qué tipo de remitente debo usar tiene la comparación completa, y SMS bidireccional cubre lo que Bird ofrece para el lado de respuesta.

En resumen

  1. Unidireccional es una propiedad del remitente, no una configuración.

    Un nombre no tiene dirección, así que no se le puede enviar nada de vuelta. Un remitente numérico aún necesita capacidad SMS y una ruta de entrada; un remitente alfanumérico no puede recibir respuestas.

  2. Un destino puede ser unidireccional para un tipo que por lo demás soporta.

    Cada tipo de remitente que un país soporta reporta su propia dirección, así que el mismo tipo de número puede ser bidireccional en un destino y unidireccional en otro.

  3. Una respuesta llega como un evento, no como un sondeo.

    Bird almacena el mensaje entrante y emite sms.received con el cuerpo, el desglose de segmentos, ambos números y el operador cuando el carrier lo reporta.

  4. Tu respuesta de API es un envío con sus propias verificaciones.

    Usa un remitente elegible y respeta la solicitud del destinatario. Las confirmaciones internas de palabras clave no otorgan a tu aplicación una exención de registro ni de supresión.

Ponlo en práctica.

Continúa con la documentación, guías y ejemplos sobre este tema. Los recursos están en inglés.

Obtener un resumen de implementación

Construye sobre la misma red.

Obtén una clave API de prueba de inmediato. El acceso a producción se desbloquea cuando añades un método de pago y verificas un remitente.

Tu próxima idea.
Lista para conectar.