Se a aplicação que você deseja integrar não tem suporte nativo aos Webhooks do Umbler Talk 2.0, você precisará escrever a sua própria para fazer o intermédio. Receber estes eventos e fazer as ações que deseja.

Se é isso que deseja, os próximos tópicos lhe ajudarão com a integração. Familiaridade com o tópico é recomendado. Senão, a ajuda de desenvolvedores pode ser necessária.

{
  "Type": "Message", // String contendo o tipo do evento. Veja o t�pico abaixo para mais detalhes das possibilidades
  "EventDate": "2024-02-07T18:44:01.3135533Z", // A data que o evento ocorreu, no formato ISO 8601
  "Payload": {
    "Type": "Chat", // At� o momento, sempre Chat. Corresponde ao objeto BasicChatModel que � o mesmo que est� descrito no schema da API.
    "Content": { } // O objeto correspondente a propriedade Type. Atualmente, sempre do tipo BasicChatModel
  },
  "EventId": "ZcPPcWpimiD3EiER" // Id �nico para cada evento. Persiste entre re-tentativas
}

Message
Uma mensagem nova do contato ou de um membro. Pode ser analisada via o objeto LastMessage do payload. Propriedades notáveis desse objeto incluem:

Content: O conteúdo do texto da mensagem

IsPrivate: Mensagens "privadas" é como chamamos as notas internas. Indica que é uma nota quando true

Source: Informa quem foi a origem da mensagem. (contato, membro, bot etc)

MemberTranfer
Um chat foi transferido para algum membro, ou foi removido. A propriedade relevante do payload é a OrganizationMember.

ChatClosed
Ocorre quando um chat é finalizado. 

ChatSectorChanged
Ocorre quando o setor de um chat é alterado. A propriedade relevante do payload é a Sector.

ChatPrivateStatusChanged
Ocorre quando um chat é privado ou des-privado. As propriedades relevantes do payload são Private e OrganizationMember (de quem pertence caso esteja privado).

Observação: Ainda não temos eventos para atualizações de status de mensagens enviadas.

Para o envio do webhook ser considerado como sucedido, precisa atender os seguintes requisitos:

• O código de status deve ser entre 200 e 299
• O tempo de resposta deve ser inferior a 5 segundos
• O corpo de resposta (se houver) é ignorado.

Por causa do tempo de resposta máximo de 5 segundos, recomendamos que a resposta seja produzida o mais cedo possível de quando é recebida. Se a sua lógica inclui operações que podem demorar, um sistema de fila para que seja executado em background após enviar a resposta seria o ideal.

Um envio não sucedido causará até 2 re-tentativas. O número da tentativa é incluída no header x-attempt. O Id do webhook (na raiz do JSON) permanece constante durante as re-tentativas. Muitas falhas de entrega podem causar que seu Webhook seja automaticamente pausado. Veja o tópico abaixo para mais informações.

Diariamente é tolerado até 100 erros de envios. No momento que esse número é excedido, seu Webhook é automaticamente pausado e uma mensagem descrevendo o motivo aparecerá nele na listagem de webhooks. Além disso, é importar ressaltar:

• A contagem de erros é zerada toda meia noite UTC-0 (em 3 horas) ou quando o Webhook é des-pausado.
• A contagem é incrementada apenas se a última re-tentativa falhar a ser entregue.