Documentación

Notificaciones push

Entrega respuestas de operadores y campañas mientras la aplicación está cerrada, con un enlace directo hacia la conversación correcta. Tu aplicación es la dueña del subsistema de push; el SDK registra los tokens y abre las conversaciones.

Qué envía Respondo#

  • Pushes de mensajes: una respuesta de un operador o de la IA en una conversación de la que el visitante forma parte.
  • Pushes de campaña: campañas de push salientes, que además reportan un beacon de apertura.

Los pushes de mensajes siempre llevan un enlace directo con la forma respondo://conversation/<id>. Los pushes de campaña llevan el enlace directo configurado en la campaña — es opcional, y cuando no está definido el push no contiene ningún enlace directo.

Apple (APNs)#

El push de iOS funciona directamente sobre APNs, sin dependencia de Firebase. Desde tu cuenta de Apple Developer, obtén:

  • Una clave de autenticación de APNs (clave de token .p8).
  • El Key ID de esa clave.
  • Tu Team ID.
  • El bundle id de la aplicación.

Google (FCM)#

El push de Android pasa por Firebase Cloud Messaging. Desde tu proyecto de Firebase, obtén:

  • Un JSON de cuenta de servicio con el rol de Cloud Messaging.
  • El ID del proyecto de Firebase (consola de Firebase → Project settings) — se introduce como campo propio en el formulario de push del panel junto al JSON de la cuenta de servicio.
  • El nombre de paquete de la aplicación Android, y conecta la aplicación al mismo proyecto de Firebase (google-services.json).

Configurar en Respondo#

Añade la clave de APNs y la cuenta de servicio de FCM con su ID de proyecto a tu canal de widget en el panel de control. Eso es todo lo que Respondo necesita para enviar a ambas plataformas.

La configuración de las credenciales a través de la API y la referencia completa de campos se tratan en la guía de configuración de push que se entrega con tu acceso al SDK.

Formato del payload#

El payload siempre reside bajo una clave raíz respondo: su presencia es la forma en que el SDK distingue su propio push de los demás (en iOS en userInfo, en Android como una cadena JSON en data["respondo"]).

payload de respondojson
{
  "respondo": {
    "type": "message",
    "conversation_id": "a1c4e7b2-5d38-4f6a-9e10-3b7c2d5f8a90",
    "message_id": "e9a3c1f6-4b8d-4e0a-b5f3-1d7b2a4e9c63",
    "deep_link": "respondo://conversation/a1c4e7b2-5d38-4f6a-9e10-3b7c2d5f8a90"
  }
}

Todos los valores son cadenas planas. El título y el cuerpo de la notificación los entrega el transporte de la plataforma — aps.alert en APNs y message.notification en FCM — no dentro del objeto respondo.

Los pushes de campaña también incluyen un delivery_id que se usa para reportar el beacon de apertura, y pueden llevar claves adicionales de cadenas planas provenientes de los datos de push de la campaña.

Gestionar toques y primer plano#

Al tocar una notificación, entrega el payload en crudo al SDK. Este analiza el payload y abre la conversación correcta, devolviendo false si el push no es un push de Respondo (gestiónalo tú mismo en ese caso).

Gestionar un toque (por plataforma)text
Android:  RespondoPushPayload.from(data)?.let { Respondo.handlePush(it) }
iOS:      Respondo.handlePush(userInfo: userInfo)
Flutter:  Respondo.handlePushData(message.data)

Los duplicados se colapsan por message_id, y mientras la misma conversación está abierta en primer plano, la notificación del sistema se suprime: el SDK gestiona ambos casos automáticamente.

Registrar tokens de dispositivo#

Tu aplicación obtiene el token de dispositivo de su subsistema de push y lo pasa a setPushToken. Llama a clearPushToken al cerrar sesión.

Qué token pasar. El backend enruta cada entrega por plataforma —iOS va a APNs directamente, Android va a FCM— así que debes registrar el token del transporte nativo de la plataforma, no el que tu biblioteca de push devuelva por casualidad:
  • Android: el token de registro de FCM de FirebaseMessaging.getToken().
  • iOS (nativo): el token de dispositivo de APNs (hexadecimal) de didRegisterForRemoteNotificationsWithDeviceToken.
  • iOS vía Flutter (firebase_messaging): usa getAPNSToken(), no getToken(). Pasar el token de FCM en iOS lo envía a APNs, donde no es un token de dispositivo válido y los pushes nunca llegan. getAPNSToken() puede ser null durante los primeros instantes tras el arranque: reinténtalo tras un breve retraso si es así.
Android — FirebaseMessagingServicekotlin
override fun onNewToken(token: String) {
    Respondo.setPushToken(token)
}
iOS — AppDelegateswift
func application(
    _ application: UIApplication,
    didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data
) {
    let token = deviceToken.map { String(format: "%02x", $0) }.joined()
    Respondo.setPushToken(token)
}
Flutter — firebase_messagingdart
// iOS necesita el token de APNs; Android necesita el token de FCM.
final token = Platform.isIOS
    ? await FirebaseMessaging.instance.getAPNSToken()
    : await FirebaseMessaging.instance.getToken();
if (token != null) Respondo.setPushToken(token);

// FCM rota su token de registro; mantén Android sincronizado.
if (!Platform.isIOS) {
  FirebaseMessaging.instance.onTokenRefresh.listen(Respondo.setPushToken);
}