Notificações push

O que o Respondo envia#

• Pushes de mensagem — uma resposta de um atendente ou da IA em uma conversa da qual o visitante faz parte.
• Pushes de campanha — campanhas de push de saída, que também reportam um beacon de abertura.

Os pushes de mensagem transportam sempre um deep link no formato respondo://conversation/<id>. Os pushes de campanha transportam o deep link configurado na campanha — ele é opcional, e quando não está definido o push não contém deep link.

Apple (APNs)#

O push no iOS roda diretamente sobre APNs — sem dependência do Firebase. A partir da sua conta Apple Developer, obtenha:

• Uma APNs Auth Key (chave de token .p8).
• O Key ID dessa chave.
• O seu Team ID.
• O bundle id do app.

Google (FCM)#

O push no Android passa pelo Firebase Cloud Messaging. A partir do seu projeto Firebase, obtenha:

• Um JSON de service account com o papel Cloud Messaging.
• O ID do projeto Firebase (console do Firebase → Project settings) — inserido como campo próprio no formulário de push do dashboard, ao lado do JSON de service account.
• O package name do app Android, e ligue a app ao mesmo projeto Firebase (google-services.json).

Configurar no Respondo#

Adicione a chave APNs e a service account FCM com o seu ID de projeto ao canal do seu widget no dashboard. É tudo o que o Respondo precisa para enviar para ambas as plataformas.

Formato do payload#

O payload vive sempre sob uma chave raiz respondo — a sua presença é como o SDK distingue o seu próprio push dos restantes (no iOS em userInfo, no Android como uma string JSON em data["respondo"]).

{
  "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 os valores são strings simples. O título e o corpo da notificação são entregues pelo transporte da plataforma — aps.alert no APNs e message.notification no FCM — e não dentro do objeto respondo.

Os pushes de campanha incluem também um delivery_id usado para reportar o beacon de abertura, e podem transportar chaves extras de strings simples dos dados de push da campanha.

Processar toques & primeiro plano#

Ao tocar em uma notificação, entregue o payload bruto ao SDK. Ele analisa o payload e abre a conversa certa, retornando false se o push não for um push do Respondo (nesse caso, trate-o você mesmo).

Android:  RespondoPushPayload.from(data)?.let { Respondo.handlePush(it) }
iOS:      Respondo.handlePush(userInfo: userInfo)
Flutter:  Respondo.handlePushData(message.data)

Os duplicados são colapsados por message_id, e enquanto a mesma conversa está aberta em primeiro plano a notificação do sistema é suprimida — o SDK trata de ambos automaticamente.

Registrar tokens de dispositivo#

O seu app obtém o token do dispositivo do seu subsistema de push e passa-o a setPushToken. Chame clearPushToken no logout.

override fun onNewToken(token: String) {
    Respondo.setPushToken(token)
}

func application(
    _ application: UIApplication,
    didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data
) {
    let token = deviceToken.map { String(format: "%02x", $0) }.joined()
    Respondo.setPushToken(token)
}

// O iOS precisa do token APNs; o Android precisa do token FCM.
final token = Platform.isIOS
    ? await FirebaseMessaging.instance.getAPNSToken()
    : await FirebaseMessaging.instance.getToken();
if (token != null) Respondo.setPushToken(token);

// O FCM roda o seu token de registro; mantenha o Android sincronizado.
if (!Platform.isIOS) {
  FirebaseMessaging.instance.onTokenRefresh.listen(Respondo.setPushToken);
}