> For the complete documentation index, see [llms.txt](https://docs.helena.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.helena.app/duvidas-e-novidades/novidades-de-produto/julho-de-2026/30-07-2026.md).
# 30/07/2026
### **📊 Relatórios: Corrigida divergência entre Indicadores e Relatório de Atendimentos**
Os valores exibidos na aba de Indicadores podiam divergir dos números do Relatório de Atendimentos mesmo ao aplicar o mesmo perÃodo de filtro, especialmente em atendimentos criados ou concluÃdos perto da virada do dia.
Isso acontecia porque cada tela convertia o horário para o fuso da conta de forma diferente, fazendo com que um mesmo atendimento fosse contado em dias distintos dependendo de onde era consultado. Além disso, não ficava claro que os **Indicadores** consideram apenas atendimentos individuais, enquanto o **Relatório de Atendimentos** também inclui atendimentos em grupo. O que reforçava a sensação de inconsistência entre as duas telas.
**✅ O que foi corrigido?**
O cálculo de fuso horário foi padronizado e a distinção entre tipos de atendimento ficou explÃcita:
* **Indicadores e Relatório de Atendimentos** agora usam a mesma conversão de fuso horário, garantindo que atendimentos criados ou concluÃdos próximos à virada do dia sejam contabilizados no mesmo dia em ambas as telas
* O Relatório de Atendimentos passou a contar com um **filtro por tipo de atendimento** (Individual/Grupo), facilitando a comparação com os Indicadores
* Os Indicadores agora exibem uma seção de "Critérios", deixando claro que os cálculos consideram apenas atendimentos individuais
* Ao filtrar por atendimentos do tipo Grupo, as ações de concluir e exportar ficam desabilitadas, com um aviso explicativo ao usuário
### **📊 Relatórios: Corrigida inconsistência entre contagem e detalhamento no Relatório de Indicadores**
No Relatório de Indicadores, o número de atendimentos exibido no **contador de uma classificação** podia divergir da quantidade exibida ao abrir o detalhamento. Em alguns casos o contador mostrava atendimentos que simplesmente não apareciam na listagem.
Isso acontecia porque o contador e o detalhamento calculavam o perÃodo selecionado de formas diferentes, gerando uma pequena diferença no fuso horário considerado por cada um. Na prática, atendimentos concluÃdos próximos à virada do dia podiam entrar na contagem sem aparecer na lista correspondente.
**✅ O que foi corrigido?**
O cálculo de perÃodo e fuso horário foi padronizado entre todos os pontos do relatório, eliminando a divergência:
* O contador de cada classificação agora usa exatamente o mesmo cálculo de perÃodo que o detalhamento e os relatórios de atendimento
* A quantidade exibida no contador passa a corresponder sempre ao que é listado no detalhamento, tanto para um único dia quanto para perÃodos com vários dias
* Atendimentos concluÃdos nos horários limites do dia (próximos à meia-noite) agora são considerados de forma consistente em contador, detalhamento e relatórios
### **🔗 Integrações: Metadados de alteração no webhook de Card Alterado**
Ao alterar um campo personalizado em um card, o webhook **Card Alterado** disparava normalmente, mas sem informar o que havia mudado: o campo changeMetadata, que deveria trazer o nome do campo alterado e os valores antigo e novo, chegava vazio (null). Isso impedia identificar o que de fato havia sido alterado a partir do próprio webhook.
**O que foi corrigido?**
O preenchimento do changeMetadata foi corrigido para cobrir todos os cenários de alteração de campo:
* Alterações em campos personalizados agora disparam o webhook com o nome do campo, o valor antigo e o valor novo devidamente preenchidos
* O comportamento passou a ser o mesmo para campos padrão e personalizados
* Quando um campo vazio é preenchido pela primeira vez, ou quando um valor existente é apagado, o changeMetadata reflete corretamente essa transição
* Quando várias alterações acontecem em uma mesma ação, cada campo alterado aparece corretamente no changeMetadata
### **🔗API: Correção no filtro de destinatário do endpoint de Mensagens Agendadas**
Ao consultar o endpoint público de listagem de mensagens agendadas (Chat > Mensagens Agendadas > Listar) informando o destinatário (contato) no parâmetro TO, a resposta podia trazer mensagens agendadas de outros contatos, mesmo quando o contato informado não tinha nenhuma mensagem agendada, em vez de retornar uma lista vazia.
**O que foi corrigido?**
O filtro por destinatário foi ajustado para considerar corretamente o contato informado:
* O filtro por **TO** agora funciona corretamente tanto por número de telefone quanto por ID do contato
* Consultas para contatos sem mensagens agendadas retornam lista vazia (TotalItems: 0), em vez de trazer registros de outros contatos
* O filtro por destinatário continua funcionando corretamente quando combinado a outros filtros (como canal) e junto com a paginação
### **🔗 API: Atualizar etiquetas de cards via API sem perder as existentes**
Ao usar o endpoint de atualização de cards (CRM > Atualizar) para incluir uma etiqueta, o sistema substituÃa todas as etiquetas já existentes no card pela nova informada. Um card com as etiquetas "VIP" e "Financeiro" que recebesse uma requisição informando apenas a etiqueta ex."Urgente" ficava somente com essa etiqueta vinculada. As demais eram removidas sem aviso. Isso acontecia porque o endpoint não oferecia nenhuma forma de escolher como as etiquetas deveriam ser tratadas na requisição.
✅ **O que foi corrigido?**
Foi adicionado o campo upsertTagOperation, dentro da seção options, para controlar esse comportamento:
* **InsertIfNotExists**: adiciona apenas as etiquetas que ainda não estão no card, mantendo as demais intactas
* **DeleteIfExists**: remove apenas as etiquetas informadas que já estão no card, preservando as outras
* **ReplaceAll**: substitui todas as etiquetas pelas informadas na requisição (comportamento padrão, mantendo compatibilidade com integrações já existentes)
* Requisições com um valor inválido nesse campo agora retornam erro de validação, em vez de serem aceitas silenciosamente
