Quais tipos de eventos podem disparar webhooks no Dailybot?

O Dailybot suporta webhooks para check-in completado, relatório de agente recebido, bloqueio detectado, limiar de humor cruzado, workflow disparado, kudos enviado e formulário enviado. Cada tipo de evento tem uma estrutura de payload distinta documentada na referência de webhooks.

Como o Dailybot autentica as entregas de webhooks?

Cada endpoint de webhook recebe um segredo de assinatura ao ser registrado. O Dailybot inclui uma assinatura HMAC-SHA256 no cabeçalho X-Dailybot-Signature de cada entrega. Os consumidores devem verificar a assinatura contra o payload usando o segredo compartilhado antes de processar.

Qual é a política de retentativas do Dailybot para entregas de webhook que falharam?

O Dailybot retenta entregas que falharam (respostas não-2xx ou timeouts) até 5 vezes com backoff exponencial: 30 segundos, 2 minutos, 10 minutos, 1 hora e 6 horas. Após esgotar todas as retentativas, a entrega é marcada como falha nos logs de webhook.

Referência de webhooks e eventos - Academy

Webhooks permitem que você envie eventos do Dailybot para seus próprios sistemas em tempo real. Em vez de fazer polling na API, registre uma URL e o Dailybot envia um POST HTTP com um payload estruturado toda vez que um evento relevante dispara. Esta referência cobre cada tipo de evento, o formato de payload, a autenticação, o comportamento de retentativas e integrações práticas de exemplo.

Registrando um endpoint de webhook

No dashboard do Dailybot, vá a Configurações e depois Webhooks. Clique em “Adicionar endpoint” e forneça:

URL — O endpoint HTTPS que receberá as requisições POST. HTTP não é aceito em produção.
Eventos — Selecione quais tipos de eventos este endpoint deve receber. Você pode assinar todos os eventos ou escolher específicos.
Segredo — O Dailybot gera um segredo de assinatura para o endpoint. Guarde-o com segurança — você o usará para verificar as entregas recebidas.

Uma vez salvo, o endpoint fica ativo imediatamente. Você pode testá-lo disparando um evento de amostra pela página de configuração de webhooks.

Tipos de eventos

check_in.completed

Dispara quando um membro da equipe termina de responder a um check-in.

Campos-chave do payload: check_in_id, user_id, user_name, team_id, responses (array de pares pergunta/resposta), completed_at (timestamp ISO 8601).

agent_report.received

Dispara quando um agente de código envia um relatório de progresso.

Campos-chave do payload: agent_id, agent_type (ex., “cursor”, “claude-code”), workspace_id, report_body, metadata (modelo, branch, repositório), received_at.

blocker.detected

Dispara quando uma resposta de check-in corresponde às regras de detecção de bloqueios.

Campos-chave do payload: check_in_id, user_id, user_name, matched_keywords (array), original_response, follow_up_responses (se acompanhamentos condicionais estiverem configurados), detected_at.

mood.threshold_crossed

Dispara quando a pontuação de humor de uma equipe ou indivíduo cruza um limiar configurado.

Campos-chave do payload: team_id, user_id (null para nível de equipe), current_score, threshold, direction (“above” ou “below”), period, crossed_at.

workflow.triggered

Dispara quando uma regra de workflow personalizado é ativada.

Campos-chave do payload: workflow_id, workflow_name, trigger_type, trigger_data, actions_executed (array), triggered_at.

kudos.sent

Dispara quando um membro da equipe envia kudos a um colega.

Campos-chave do payload: sender_id, sender_name, recipient_id, recipient_name, message, value (se valores da equipe estiverem configurados), sent_at.

form.submitted

Dispara quando o envio de um formulário é completado.

Campos-chave do payload: form_id, form_name, submitter_id, submitter_name, responses (array de pares campo/valor), submitted_at.

Estrutura do payload

Toda entrega de webhook segue um envelope consistente:

{
  "event": "check_in.completed",
  "version": "1",
  "timestamp": "2026-03-20T14:30:00Z",
  "delivery_id": "d_abc123",
  "data": {
    // Campos específicos do evento
  }
}

O campo version indica a versão do esquema do payload. Quando mudanças significativas são introduzidas, a versão incrementa e você pode migrar no seu próprio ritmo.

O delivery_id é único por tentativa de entrega, incluindo retentativas. Use-o para idempotência — se seu endpoint receber o mesmo delivery_id duas vezes, pule o duplicado.

Autenticação e verificação

Cada entrega inclui dois cabeçalhos para verificação:

X-Dailybot-Signature — Digest hex HMAC-SHA256 do corpo bruto da requisição, computado usando o segredo de assinatura do seu endpoint.
X-Dailybot-Timestamp — Timestamp Unix de quando a entrega foi enviada. Use para rejeitar entregas obsoletas (ex., mais de 5 minutos) e prevenir ataques de replay.

Para verificar uma entrega:

Leia o corpo bruto da requisição (não faça parse do JSON primeiro).
Compute HMAC-SHA256 de {timestamp}.{body} usando seu segredo de assinatura.
Compare a assinatura computada contra o cabeçalho X-Dailybot-Signature usando uma comparação de tempo constante.
Rejeite se o timestamp for mais antigo que sua janela de tolerância.

Política de retentativas

Se seu endpoint retorna um código de status não-2xx ou atinge o timeout (limite de 30 segundos), o Dailybot retenta com backoff exponencial:

Tentativa	Espera
1ª retentativa	30 segundos
2ª retentativa	2 minutos
3ª retentativa	10 minutos
4ª retentativa	1 hora
5ª retentativa	6 horas

Após 5 retentativas falhadas, a entrega é marcada como falha. Você pode ver o histórico de entregas e reenviar entregas falhadas pela página de configuração de webhooks.

Se um endpoint acumula muitas falhas consecutivas, o Dailybot o desabilita automaticamente e envia uma notificação ao administrador do workspace. Reative-o pelo dashboard após corrigir o problema.

Integrações de exemplo

Postando alertas de bloqueios no Slack

Assine eventos blocker.detected. Quando o webhook disparar, extraia user_name, original_response e matched_keywords do payload. Formate uma mensagem do Slack e envie com POST para seu canal #bloqueios usando a API de Incoming Webhooks do Slack.

Disparando pipelines de CI/CD

Assine eventos agent_report.received. Quando um agente reporta que uma branch de feature está pronta para revisão, faça parse do campo metadata.branch e dispare seu pipeline de CI via API do GitHub Actions ou GitLab.

Atualizando ferramentas de gestão de projetos

Assine eventos check_in.completed. Faça parse das respostas procurando menções de tarefas ou palavras-chave de status, e atualize os cartões correspondentes no Jira, Linear ou Asana usando suas APIs. Isso mantém os quadros de projeto sincronizados com o que as pessoas realmente reportam em seus standups.

Alertas ao gestor por humor

Assine eventos mood.threshold_crossed. Quando o humor de uma equipe cai abaixo de uma pontuação configurada, envie um email ou DM do Slack ao gestor da equipe com os dados de tendência para que possa conversar com a equipe proativamente.

Boas práticas

Comece com pouco. Assine um ou dois tipos de eventos e construa a partir daí. Assinar tudo cria ruído antes de ter handlers para processar.

Use idempotência. Seu endpoint pode receber a mesma entrega mais de uma vez devido a retentativas ou problemas de rede. Verifique o delivery_id antes de processar.

Responda rápido. Retorne um código de status 200 assim que receber o payload. Faça o processamento pesado de forma assíncrona. Se seu endpoint demora demais, o Dailybot retentará e você pode processar duplicados.

Monitore a saúde das entregas. Verifique os logs de webhooks no Dailybot periodicamente. Um pico em falhas geralmente significa que seu endpoint está fora do ar ou retornando erros — capture isso antes que a escalação desabilite o endpoint.