Aplicativos na barra lateral, o código do erro de envio e o aviso de follow-up que não saía
Um aplicativo criado no Painel de Aplicativos agora pode ficar na barra lateral, com o nome que você escolher, em vez de só dentro de uma conversa. Quando o envio de uma mensagem falha, o código que o provedor devolveu passa a acompanhar o motivo — chave estável para quem trata erro em automação. E um follow-up interrompido porque o modelo foi apagado volta a disparar o aviso que antes ficava só na tela.
- NovidadeAplicativo do painel pode ficar na barra lateral. Na criação você escolhe entre "Dentro da conversa" e "Na barra lateral" — na barra ele vira um item próprio, com o nome que você deu, e abre sem precisar entrar numa conversa.
- NovidadeO código do erro do provedor acompanha o motivo da falha. Além do texto, a mensagem falhada passa a trazer o código que o provedor devolveu (por exemplo 131026, número sem WhatsApp). O texto muda com idioma e redação; o código não.
- CorreçãoFollow-up interrompido por modelo apagado volta a avisar. Ele já aparecia como falho na tela, mas o webhook follow_up_failed não era disparado nessas situações — quem acompanha por automação não ficava sabendo.
Disponibilidade
Esta versão está publicada no Docker Hub. Ela ainda não foi instalada nos servidores — a atualização de cada instalação é um passo separado.
Aplicativos na barra lateral
Até agora um aplicativo criado no Painel de Aplicativos só existia como aba dentro da conversa: para abrir a integração o atendente precisava abrir uma conversa qualquer, mesmo quando o aplicativo não tinha nada a ver com ela.
Na criação você agora escolhe onde ele vive. A escolha é exclusiva — um aplicativo fica em um lugar ou no outro, nunca nos dois. Os que já existem continuam exatamente onde estavam.
Vale saber, se o seu aplicativo lê o contexto: aberto pela barra lateral não há conversa nem contato para enviar, e ele recebe essa informação explicitamente, junto com a indicação de onde foi aberto.
O código do erro de envio
Quando um envio falha, o provedor devolve um texto e, quase sempre, um código. Nós entregávamos só o texto.
O texto não serve para tratar erro automaticamente: ele muda com o idioma, com a redação do provedor, e o mesmo erro produz frases diferentes conforme o provedor preencha ou não o campo de detalhe. O código não muda.
Agora os dois vão juntos, em campos separados. O texto continua exatamente como era — se você já lê aquele campo, nada muda para você; o código é adicional.
O aviso de follow-up que ficava só na tela
Quando um follow-up era interrompido porque o modelo de mensagem tinha sido
apagado — ou porque a conversa não existia mais — ele era marcado como falho e
aparecia assim na tela. Mas o aviso não saía: quem acompanha pelo webhook
follow_up_failed não era notificado nessas três situações.
Se você tem automação em cima desse evento, espere receber mais eventos do que antes. Não é uma mudança no formato do evento e sim na frequência: ele passa a sair em casos onde antes havia silêncio. Se a sua automação conta ocorrências ou dispara alerta por evento, o número vai subir sem que nada tenha piorado — o que estava ruim já estava, sem avisar.