Las aplicaciones iMessage de Linq llevan pagos, boletos, vuelos y juegos a la burbuja de iMessage a través de la parte imessage_app

Los desarrolladores de Linq ahora pueden crear aplicaciones de iMessage. Estas son miniaplicaciones interactivas que se ejecutan dentro de una conversación de iMessages.

Un usuario puede comprar, jugar, reservar un vuelo o pagar. Nada de esto requiere abandonar el hilo de iMessage. No hay ningún enlace profundo a un navegador externo. No hay ningún “toque aquí para finalizar en la aplicación”.

Anteriormente, la principal opción API de un agente era enviar un enlace. Luego, el usuario tenía que seguirlo a otro lugar. Las aplicaciones de iMessage eliminan ese traspaso.

TL;DR

La nueva parte imessage_app de Linq genera tarjetas interactivas que se pueden tocar directamente dentro de un hilo de iMessage. Una tarjeta maneja flujos de trabajo completos: juegos, pagos, boletos, vuelos, música y citas. Las tarjetas se actualizan a través de /messages/{id}/update, por lo que los cambios de estado vuelven a dibujar la misma burbuja. Una bandera interactiva alterna la experiencia en vivo versus una tarjeta de diseño estática solo con subtítulos. Es solo para iMessage sin respaldo de SMS/RCS, y el procesamiento enriquecido necesita que tengas tu aplicación instalada.

Aplicaciones de iMessage

Una aplicación iMessage es una tarjeta que se puede tocar y que abre una experiencia interactiva en el lugar. La tarjeta se convierte en tu aplicación dentro de la burbuja.

Técnicamente, es una nueva parte del mensaje con tipo: “imessage_app”. Esto reemplaza las partes de texto, medios y enlaces que ya usa. Una extensión de Mensajes instalada extrae el contenido enriquecido de una URL que usted proporciona.

Linq es la startup de infraestructura de mensajería detrás de la API. Su plataforma permite a los agentes de IA enviar mensajes a los usuarios a través de iMessage, RCS y SMS.

Cómo funciona

Algunos detalles deciden si tu primera tarjeta se representa correctamente.

La identidad de la aplicación es la clave de representación: el objeto de la aplicación lleva team_id y bundle_id. Esos campos le indican a Mensajes qué extensión muestra la tarjeta. team_id es el identificador en mayúsculas de 10 caracteres de la aplicación. Por lo general, pasas la identidad de tu propia aplicación.

Aquí hay un modo de falla común. Una identidad no reconocida se representa silenciosamente como texto sin formato. Si team_id y bundle_id no coinciden con una extensión instalada, la tarjeta vuelve a su título. No se arroja ningún error.

Tú controlas los subtítulos; la aplicación controla la imagen: el objeto de diseño contiene el texto dibujado en la tarjeta. No hay ningún campo de imagen. La foto, el ícono y la interfaz de usuario interactiva provienen de su extensión.

campo de diseñoPosicióncaptionarriba a la izquierda, etiqueta principal en negritasubcaptionleft, debajo del captiontrailing_captionarriba a la derechatrailing_subcaptionderecha, debajo del trailing_caption

Se debe configurar al menos un campo. De lo contrario, la tarjeta aparecerá como una burbuja vacía. Mensajes trata la URL como opaca, por lo que cambiar la URL cambia lo que muestra la tarjeta.

Una bandera interactiva controla en vivo versus estático. El valor predeterminado es verdadero. Con verdadero, los destinatarios que tienen su aplicación ven la tarjeta en vivo. Configúrelo en falso para mostrar siempre la tarjeta de diseño estático.

El estado de instalación y la bandera deciden juntos el resultado. Son posibles tres resultados:

Tiene su aplicación interactiva: verdadero → la extensión muestra la tarjeta enriquecida desde su URL. Tiene su aplicación interactiva: falso → el destinatario ve la tarjeta de diseño estático. Sin aplicación → el destinatario ve los subtítulos de su diseño. Configure app_store_id para agregar una opción Obtener la aplicación.

Implementación: envío y actualización de una tarjeta

Envíe una tarjeta con Crear chat o publíquela en un chat existente con Enviar mensaje.

curl -X POST https://api.linqapp.com/api/partner/v3/chats \ -H “Autorización: Portador $LINQ_API_KEY” \ -H “Tipo de contenido: aplicación/json” \ -d ‘{ “from”: “+12052535597”, “to”: [“+12052532136″]”mensaje”: { “partes”: [
{
“type”: “imessage_app”,
“app”: {
“name”: “Example App”,
“team_id”: “A1B2C3D4E5”,
“bundle_id”: “com.example.app.MessageExtension”
},
“url”: “https://app.example.com/card?id=abc123”,
“fallback_text”: “Open in Example App”,
“layout”: {
“caption”: “Example App”,
“subcaption”: “You said: hello”
}
}
]
} }’

Las actualizaciones son la primitiva interesante. Una tarjeta entregada se puede reemplazar en su lugar haciendo referencia al mensaje original. Así es como una jugada de juego vuelve a dibujar un tablero.

curl -X POST https://api.linqapp.com/api/partner/v3/messages/{messageId}/update \ -H “Autorización: Portador $LINQ_API_KEY” \ -H “Tipo de contenido: aplicación/json” \ -d ‘{ “url”: “https://app.example.com/card?game=7f3a&move=2”, “fallback_text”: “Puntuación update”, “layout”: { “caption”: “Puntuación: 2 – 1” } }’

Algunas reglas rigen las actualizaciones. Solo se pueden cambiar la URL, el texto alternativo, el interactivo y el diseño. La identidad de la aplicación permanece fija durante la vida de la tarjeta. La tarjeta ya debe estar entregada.

Solo puedes actualizar una tarjeta imessage_app que hayas enviado. Las tarjetas entrantes no se pueden actualizar y la llamada devuelve 400. Un 409 significa que la tarjeta aún no se ha entregado. Vuelva a intentarlo después del webhook entregado por el mensaje.

Cada actualización se entrega como un mensaje nuevo con su propia identificación. La bandera interactiva no se hereda, así que reenvíela cada vez. Para actualizar nuevamente, consulte el ID del nuevo mensaje.

También puedes recibir tarjetas. Los mensajes entrantes incluyen una parte imessage_app en el webhook message.received.

Lo que puedes construir

Linq los presenta como ejemplos, no como un menú fijo. Pruebe cada uno usted mismo en la demostración interactiva a continuación (creada por Marktechpost).

Juegos: envía un movimiento y vuelve a dibujar el tablero. Un partido en vivo se convierte en una secuencia de actualizaciones de una burbuja. Pagos: envíe un pago o una solicitud de pago como tarjeta. El destinatario lo completa sin redireccionamiento. Entradas: Una tarjeta puede pasar de “Ir/No ir” a un billete confirmado en vigor. Reserva de vuelo: muestre una tarifa, permita que el usuario elija un asiento y luego actualice la tarjeta a una tarjeta de embarque. Música. Coloca una pista y deja que la gente la reproduzca en línea. La carta es un jugador, no un vínculo. Citas: permita a los usuarios deslizar perfiles y explorar coincidencias en las que ya hablan.