Olá @Renan_de_Jesus_Romer tudo bem?

Poderia dar mais detalhes sobre isso? Pois o parâmetro ticketId (deveria) especifica de qual ticket as mensagens serão retornadas. Mesmo passando o parâmetro ele retorna de todos os tickets, inclusive os mais antigos?

Olá, @BrunoC! Tudo bem e você?

Isso mesmo! Não sei se estou usando da maneira errada, mas esse está sendo o comportamento.

Por exemplo, estou enviando o seguinte comando:

{


    "id": "1757b201-2402-4538-a8f2-0d4dda788e37",


    "to": "[email protected]",


    "method": "get",


    "uri": "/tickets/47c85637-2716-4a1a-8a5c-0175755a197d/messages?getFromOwnerIfTunnel=true&$skip=0&$take=100"


}' 

Para essa consulta, a API me retornou uma lista com as 100 últimas mensagens do contato, entre elas 9 mensagens do tipo “application/vnd.iris.ticket+json”. Ou seja, o que estou observando é que o id do ticket que passo como parâmetro está servindo apenas para chegar ao contato, pois passando o id do ticket mais recente ou do mais antigo o retorno está sendo sempre o mesmo (as últimas mensagens do contato).

getFromOwnerIfTunnel deveria ser true mesmo? Você está usando estrutura de roteador?

Pensando em algumas possibilidades:

• Você está com tempo de expiração de sessão ativo e sendo ativo durante o atendimento?



• Você está fazendo transferências para outras equipes?

getFromOwnerIfTunnel deveria ser true mesmo? Você está usando estrutura de roteador?

Sim, estou usando um roteador.

Pensando em algumas possibilidades:

• 
  
  

  Você está com tempo de expiração de sessão ativo e sendo ativo durante o atendimento?
  
  
  Sim, deixei por muito tempo aquele tempo padrão de meia hora. Recentemente aumentei esse tempo para fazer alguns testes com atendimentos em que o cliente fica muito tempo sem responder, mas não acho que tenha impactado nada. Estamos desenvolvendo um canal personalizado, então tenho criado/encerrado vários atendimentos com o meu contato no WhatsApp para fazer os testes da nossa solução.

  
  
  



• 
  
  

  Você está fazendo transferências para outras equipes?
  
  
  Não, a única coisa que faço com o ticket é mudar o status (waiting/open/closed).

  
  
  

@Renan_de_Jesus_Romer, neste caso, parece ser algum comportamento inesperado ou algum detalhe que estamos deixando passado.

Seria um problema te pedir pra abrir um chamado direto com o suporte do seu plano? Por lá eles vão conseguir ir mais a fundo no caso.

Posso abrir sim, sem problema.

Obrigado pelo apoio.

Olá Renan,

Conseguiu resolver esse problema?


Nós também estamos implementando nosso canal personalizado de atendimento e esbarramos nessa questão, e tá faltando somente isso pra colocar nossa aplicação em produção… Mas, já abri chamado com o pessoal da Take e apenas o que fizeram foi corrigir a documentação, segundo eles a documentação da api é que estava errada… ou seja, parece não ter rota na api pra trazer apenas as mensagens de determinado ticket…

Obrigado pela atenção,

Reginaldo Silva

Olá, Reginaldo.

Quando abri o chamado eles também falaram que o problema estava na documentação. Eles também me deram uma solução alternativa, filtrando as mensagens a partir da data de criação do ticket. Porém isso não resolveu completamente o meu problema, pois preciso também recuperar as interações iniciais do cliente com o bot antes de chegar no atendimento humano, que ocorrem antes dessa data de abertura do ticket.

Algo que pensei mas não cheguei a implementar foi filtrar as mensagens com base no metadado “stateId”, buscando pelo id do bloco de boas vindas do builder. Quando eu encontrar uma mensagem com esse id irei saber onde está o início daquela conversa.

De qualquer forma vou colocar aqui embaixo a alternativa que eles me enviaram, pode ser que para o seu cenário resolva.

Para buscar as mensagens de um ticket é necessário, utilizar o endpoint /threads Blip Docs | API Reference, filtrando com as informações do ticket desejado. Veja um exemplo de como buscar todas as mensagens de um ticket

Busque o ticket desejado no https://docs.blip.ai/?http#get-a-ticket


{


“id”: “4bcde23c-bbe8-4913-a8f8-0175adc80bc1”,


“sequentialId”: 18,


“ownerIdentity”: “[email protected]”,


“customerIdentity”: “[email protected]”,


“customerDomain”: “0mn.io”,


“agentIdentity”: “caiof%40take.net@blip.ai”,


“provider”: “Lime”,


“status”: “ClosedAttendant”,


“storageDate”: “2020-11-09T16:12:49.990Z”,


“openDate”: “2020-11-09T16:12:58.480Z”,


“closeDate”: “2020-11-09T16:14:50.320Z”,


“statusDate”: “2020-11-09T16:14:50.320Z”,


“externalId”: “4bcde23c-bbe8-4913-a8f8-0175adc80bc1”,


“rating”: 0,


“team”: “Default”,


“unreadMessages”: 0,


“closed”: true,


“closedBy”: “caiof%40take.net@blip.ai”


}

Salve o valor do openDate e ownerIdentity e utilizando o /threads, os valores no comando, considere o valor openDate para o storageDate ex: {“id”:“”,“method”:“get”,“uri”:“/threads/[email protected]?storageDate=2020-11-09T16:12:58.480Z&$take=100”}

A questão da marcação pelo “stateid” do bloco de boas vindas, já estávamos analisando a possibilidade de fazer dessa forma… entendo que é algo meio “gambiarra”, mas, enquanto o pessoal da Take não disponibiliza uma rota para buscar as mensagens pelo ticket… acho que vai funcionar assim, pelo menos, por enquanto, é a melhor solução que se apresenta… Vamos implementar aqui e te informo se ficou bom…

A questão da solução usando “/threads” funciona se você não tiver router, o que é muito difícil de não ter, né… numa arquitetura de um só bot funciona sim… mas, não é o meu caso e acredito que não seja o seu também…

Valeu!