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