Implementei uma lógica para recuperar o histórico mensagens de um contato a partir das ‘threads’. Contudo, mesmo que o usuário entre em contato em datas diferentes, as mensagens estão sendo guardadas dentro de uma mesma thread. Por exemplo, se um usuário entra em contato em uma dada data, troca algumas mensagens, e encerra o atendimento; e, posteriormente, algumas semanas depois, entrar em contato novamente, em todas as situações que vi até o momento, as mensagens são armazenadas na mesma thread, mesmo que sejam de sessões diferentes.
Há alguma maneira, via API, de identificar quando uma dada sessão foi encerrada? Por exemplo, algum indicativo nas requisições de que seriam sessões diferentes? Pensei em implementar diferentes lógicas, mas ficaria mais confortável se já existir uma maneira mais direta de obter essa informação por requisições.
Oi, @Rafael_Figueiredo. Obrigado pela resposta, mas não sei se a busca simplesmente pelas datas resolveria a questão nesse caso.
Precisava entender se existe algo que eu consiga consultar pela API que me indique se aquela mensagem do contato é, ainda, continuidade de algum atendimento específico, ou se é um novo atendimento. Você sabe se já existiria algo nesse sentido pronto, que pudesse ser obtido pela API? Pelo raciocínio das datas, não necessariamente eu teria esse indicativo; ou teria? O contato não poderia continuar um mesmo atendimento em dias diferentes? Ou existe um limite de tempo, por padrão, que o fluxo de atendimento é reiniciado?
Olá @cstefano
Oi, @Rafael_Figueiredo. Obrigado pela resposta, mas não sei se a busca simplesmente pelas datas resolveria a questão nesse caso.
Precisava entender se existe algo que eu consiga consultar pela API que me indique se aquela mensagem do contato é, ainda, continuidade de algum atendimento específico, ou se é um novo atendimento. Você sabe se já existiria algo nesse sentido pronto, que pudesse ser obtido pela API? Pelo raciocínio das datas, não necessariamente eu teria esse indicativo; ou teria? O contato não poderia continuar um mesmo atendimento em dias diferentes? Ou existe um limite de tempo, por padrão, que o fluxo de atendimento é reiniciado?
Nesse caso se for para ver se tem relação com o atendimento use essa aqui :
Oi, @Rafael_Figueiredo! Super obrigado! Eu até tinha visto essa possibilidade antes, mas eu não consegui entender como encontrar o “ticket_id”, via API, de um atendimento. Será que você saberia me indicar, também, o caminho pra obter esse identificador?
O que estou fazendo, hoje, é retomando o histórico pelo endpoint das ‘threads’, essencialmente, mas não encontrei o ticket_id por ali. Não sei se pode estar com alguma outra nomenclatura no json retornado pela API, e eu não estou realmente identificando isso.
Oi, @Rafael_Figueiredo! Super obrigado! Eu até tinha visto essa possibilidade antes, mas eu não consegui entender como encontrar o “ticket_id”, via API, de um atendimento. Será que você saberia me indicar, também, o caminho pra obter esse identificador?
O que estou fazendo, hoje, é retomando o histórico pelo endpoint das ‘threads’, essencialmente, mas não encontrei o ticket_id por ali. Não sei se pode estar com alguma outra nomenclatura no json retornado pela API, e eu não estou realmente identificando isso.
Legal, @Rafael_Figueiredo! Eu na verdade já tinha até tentado fazer dessa forma, mas o ‘items’ estava retornando vazio. Tentei novamente após o que você me orientou, mas continua assim.
Vou deixar aqui a resposta da API e a requisição que estou usando:
Requisição:
body = { "id": <id da requisição>, "to": "[email protected]", "method": "get", "uri": f"/tickets/" }
Legal, @Rafael_Figueiredo! Eu na verdade já tinha até tentado fazer dessa forma, mas o ‘items’ estava retornando vazio. Tentei novamente após o que você me orientou, mas continua assim.
Vou deixar aqui a resposta da API e a requisição que estou usando:
Requisição:
body = { "id": <id da requisição>, "to": "[email protected]", "method": "get", "uri": f"/tickets/" }
@cstefano acredito que você usou a chave do router passe a chave do bot de atendimento e ve se funciona.
@cstefano acredito que você usou a chave do router passe a chave do bot de atendimento e ve se funciona.
@Rafael_Figueiredo, a chave do bot eu segui os passos deste artigo aqui para recuperar a chave do bot, mas já era a que estou utilizando. É ali mesmo que encontro essa informação, certo?
@cstefano acredito que você usou a chave do router passe a chave do bot de atendimento e ve se funciona.
@Rafael_Figueiredo, a chave do bot eu segui os passos deste artigo aqui para recuperar a chave do bot, mas já era a que estou utilizando. É ali mesmo que encontro essa informação, certo?
sim mas há diferença entre o router e o bot de atendimento.
@cstefano , tudo bem?
Estava com um problema parecido com o seu e inclusive utilizei esse fórum aqui para pensar uma solução. Acredito que ela vá te ajudar no que você está querendo resolver, visto que seu problema era bem parecido com o meu.
Vou compartilhar com você por aqui e com mais pessoas que tiverem essa necessidade. Para o meu caso de uso, funcionou perfeitamente. E o que eu precisava era ter o registro das conversas separadamente, por cada sessão.
A minha solução passa por dois momentos chave: o início da sessão e a finalização da sessão.
Início da sessão
O início da sessão, no meu caso, sempre é no bloco início do bot principal. Nas ações de saída do bloco, introduzi um script para salvar a data e hora daquele momento no formato ISO 8601 (ex.: 2024-07-25T13:16:05.007Z). Esse formato é necessário para a requisição que é realizada posteriormente.
function run() { // Obtém a data e hora atual let dateObject = new Date();
// Converte para o formato ISO 8601 let formattedDate = dateObject.toISOString();
return formattedDate; }
No meu caso e para esse exemplo, a variável salva é storageDate
Final da sessão
No meu caso, todos os atendimentos finalizados são direcionados para um bot específico que eu chamo de “Fim do atendimento”. Nesse bot, eu faço a requisição get last messages utilizando os filtros “take”, “storageDate” e “direction”.
Veja que ao utilizar o filtro storageDate, eu utilizo a variável que eu salvei no início da sessão. Defino ainda “direction” como “asc” para obter todas as mensagens após a data filtrada.
Dessa forma, eu sempre garanto que a requisição é feita somente para aquela sessão específica, já que a data será salva no início e será utilizada para a requisição ao final da sessão.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
A analisar o ficheiro em busca de vírus
Lamentamos, mas ainda estamos a analisar o conteúdo deste ficheiro, a fim de nos certificarmos de que o mesmo é seguro para descarregar. Agradecemos que tentes de novo dentro de poucos minutos.