action.recorded. Um gatilho é uma regra sua sobre o que a memória sabe, com parâmetros, janela e deduplicação por sujeito, como “promessa da empresa vencida há um dia”. Nos dois casos, a Niadra avisa por webhook, e quem age é o seu agente ou o seu sistema. Gatilho nunca chama sistema de registro, nunca abre ticket, nunca manda mensagem ao cliente final e nunca ramifica.
Tipos de evento de saída
Endpoints, assinaturas e regras de gatilho são configuração versionada na API de controle, alterada por diffs que uma pessoa aprova. Todo endpoint pertence a uma fonte, e um evento sobre a memória só chega ao endpoint cuja fonte pode ler o item de que ele fala, pela mesma política do contexto: finalidade, audiência e o nível de verificação que a fonte alcança. Com a política inicial, o desfecho de uma conversa de saúde nunca chega ao CRM de cobrança, e
trait.added de overdue_invoices só chega a fontes com a finalidade billing. Uma regra de gatilho só é aceita, e só dispara, se a condição e o conteúdo do aviso puderem ser lidos pela fonte do endpoint: um diff que deixaria uma regra calada é recusado quando é enviado e de novo quando é aprovado. trait.present(overdue_invoices) nunca chega a um sistema de marketing. As condições e os avisos contam só os itens que chegaram por handles confirmados: um episódio que veio por um vínculo não confirmado não completa uma recorrência nem dispara um recontato, e o webhook nunca leva o id dele. Uma confirmação, uma união ou uma separação reavaliam as regras do perfil na hora, e uma separação retira os disparos cuja evidência saiu com o handle.
Um endpoint com format ocsf ou hec não recebe esses eventos: ele recebe o fluxo de comprovantes do espaço para o seu SIEM, assinado e com as mesmas novas tentativas. Veja Comprovantes e auditoria.
No Console, a tela Avisos monta a regra a partir do catálogo, sem JSON: você escolhe a condição, os parâmetros e o endpoint, testa e envia para aprovação com um motivo. Uma regra em uso é ajustada ali mesmo, com o mesmo ID e a versão seguinte, e ligada ou desligada por um diff. O plano de controle confere o diff quando ele chega e de novo na aprovação, contra os documentos daquele momento, e recusa:
- uma regra cujo endpoint não pode receber o aviso: é um fluxo de SIEM, não assina
trigger.fired, é de uma fonte de análise ou de exportação, recebe um aviso de identidade sendo agente de atendimento, ou não tem finalidade nem audiência em comum com o padrão do aviso; - uma regra
trait.presentque nomeia um padrão desligado ou que não existe; - uma regra
context_use.repetition_ratecom parâmetros que a varredura não consegue ler ou com umasource_idque não existe no espaço; - um endpoint que assina um tipo de evento que a Niadra não manda: a lista aceita é exatamente a tabela acima;
- um endpoint ou um mapeamento novo para uma fonte cortada;
- um documento com mais de 50 regras de aviso.
endpoint_disabled, os webhooks do mapeamento são recusados, e as regras de aviso apontadas para eles deixam de valer). Os documentos continuam com eles, como histórico.
O desfecho de cada atendimento
Para o seu CRM registrar como cada atendimento terminou, assineconversation.outcome, open_item.closed e action.recorded. Nenhum deles leva o texto da conversa.
conversation.outcome sai quando a memória de uma conversa ou tarefa fica pronta (by: extraction, com as pendências que ela deixou abertas em open_item_ids) e quando uma correção muda o desfecho (by: feedback, com version maior). Leva os rótulos das suas listas fechadas, como intenção, categoria normalizada e desfecho, nunca o resumo nem a resolução. conversation_id é o id da conversa no seu sistema e vem nulo quando parece um telefone, um e-mail ou um id do WhatsApp.
open_item.closed diz qual pendência fechou (open_item_id, owner, object, expected_operation, due_at e, em opened_in, a sessão e a fonte que a abriram) e o que a fechou, em closed_by: kind action, com action_id e operation, quando foi a ação de um agente; system_event, com event_id, quando foi um evento do sistema de registro; conversation, com session_id, quando uma conversa posterior resolveu; ou feedback. links.open abre a linha do tempo do objeto ou, sem objeto, a memória do perfil. open_item.reopened desfaz um fechamento quando a sessão da ação que fechou teve um turno marcado como injeção e a ação foi posta em quarentena (reason: closing_action_quarantined, com o action_id).
O catálogo de gatilhos
Condições novas entram pelo catálogo do produto, nunca por texto livre. Uma regra dispara no máximo uma vez por sujeito por janela (24 horas por padrão), e a mesma evidência nunca dispara a mesma regra duas vezes; o teto é de 100 disparos por minuto por espaço, e um espaço tem no máximo 50 regras de gatilho, ligadas ou não. As condições sobre um perfil são avaliadas logo depois que a memória dele muda; os prazos e as condições sobre uma fonte, a cada 5 minutos. Um disparo atrasado, mais de 2 horas depois de a condição passar a valer (ou o que
late_after_minutes disser), sai marcado como late ou é suprimido, conforme a regra.
Condições sobre uma fonte
source.silent, source.gap e context_use.repetition_rate falam de uma fonte, não de um cliente. O sujeito do aviso é a fonte ("kind": "source", com o id dela em pseudonym), e a varredura de 5 minutos avalia as três.
source.silentobserva as fontes que mandaram eventos nos últimos 30 dias. Cada silêncio é uma ocorrência própria: a fonte que volta e cala de novo avisa de novo.context_use.repetition_ratelê a medição diária de Aproveitamento do contexto. Dispara quando, nos últimoswindow_daysdias (7 por padrão, até 90), as perguntas repetidas passam da fraçãoabove(0,2 por padrão) das perguntas da fonte, com pelo menosmin_questionsperguntas (30 por padrão) para o número valer. Semsource_id, cada fonte é observada por si. O grupo de controle de um experimento fica de fora, porque nunca recebeu o contexto. Um período acima do limite avisa uma vez, contado do dia em que começou; se a taxa cair e voltar a subir, sai um aviso novo. O aviso traz emdata.detailas perguntas (questions), as repetidas (repeated), a taxa (rate), o limite (above), a janela (window_days) e o dia em que o período começou (above_since), elinks.openaponta para/v1/context-use?source_id=.... Parâmetros que a varredura não consegue ler, ou umasource_idque não existe no espaço, são recusados quando o diff é enviado e quando é aprovado.
trigger.fired para o endpoint do CRM, e o agente do seu CRM remarca a visita.
Como é uma entrega
As entregas seguem o formato aberto Standard Webhooks.links.open é a rota da API que abre o que o aviso aponta: o perfil, a memória, a linha do tempo de um objeto, um episódio ou a medição de uma fonte. Ela só funciona com uma credencial do seu espaço que tenha o escopo para isso.
Toda entrega traz três cabeçalhos:
webhook-id: único por mensagem e igual em todas as tentativas. Use para deduplicar.webhook-timestamp: segundos Unix. Recuse o que estiver a mais de 5 minutos do seu relógio.webhook-signature:v1,seguido do HMAC-SHA256 em base64 de{webhook-id}.{webhook-timestamp}.{corpo}. Durante a rotação do segredo, duas assinaturas separadas por espaço valem ao mesmo tempo.
Confira a assinatura
O segredo é gravado uma vez, pelo Console ou porPUT /v1/secrets/webhook/{id}, e começa com whsec_; a chave é a parte em base64 depois do prefixo. Confira sobre o corpo cru, antes de interpretar o JSON.
Garantias de entrega
- Pelo menos uma vez. Uma mensagem pode chegar mais de uma vez; deduplique pelo
webhook-id. - Sem garantia de ordem. As mensagens podem chegar fora de ordem; cada evento traz
as_ofe versão para você ordenar. - Novas tentativas com recuo exponencial, de 30 segundos até 4 horas entre elas, por até 24 horas. Depois disso, a entrega vai para a fila de mortos, visível no Console, e é apagada 7 dias depois de criada.
- Endpoint que falha sem parar há 24 horas, sem nenhum sucesso, deixa de receber: as entregas novas para ele vão direto para a fila de mortos com o erro
endpoint_failing_24h. Um reenvio manual que dê certo o reabre. - Saída controlada. Toda chamada para fora sai só por HTTPS e não segue redirecionamento. O endereço é resolvido e conferido a cada tentativa, e a conexão vai ao endereço conferido. Endereços privados, de loopback, link-local (inclusive o de metadados da nuvem), CGNAT, reservados e multicast são recusados.
O feed de avisos
Quem prefere puxar em vez de receber lê os mesmos eventos porGET /v1/notifications: os corpos dos webhooks, do mais antigo para o mais novo, por cursor, só ids e ponteiros. Cada item tem os campos de uma entrega (id, type, created_at, tenant, subject, data e links); o id é o do evento, e uma entrega de webhook do mesmo evento tem o id próprio dela, então quem lê os dois deduplica pelo id do evento. Sem cursor, o feed começa do início; next_cursor é onde a próxima consulta começa, e uma consulta sem nada novo responde o mesmo cursor. Os eventos ficam 7 dias. Um evento dirigido a um endpoint, ou sobre um item de memória que só algumas fontes podem ler, chega só aos webhooks dele, então o feed leva o que qualquer fonte do espaço pode ver, e nunca o texto de uma conversa. Qualquer chave de fonte lê o feed, sejam quais forem os escopos dela. O feed é a funcionalidade notifications do espaço, desligada por padrão e ligada no documento features por um diff aprovado do papel security; num espaço sem ela, a rota responde 404.
Responder a uma entrega
Responda com qualquer 2xx rápido e faça o trabalho de forma assíncrona. Uma entrega ficapending, delivered, failing enquanto tenta de novo, ou dead. Essas rotas pedem uma pessoa do Console com o papel integration (os disparos aceitam também analysis) ou uma chave de escopo admin. Para inspecionar entregas, use Entregas de webhook; para mandar de novo uma entrega morta, com o mesmo webhook-id, use Reenviar uma entrega. Para conferir um endpoint ou um fluxo de SIEM antes de depender dele, Enviar uma entrega de teste manda, uma vez e assinada como as outras, uma entrega do tipo webhook.test: o envelope de sempre com data: {"test": true}, ou um evento OCSF marcado como teste para o SIEM. Ela aparece na lista de entregas. Os disparos, com a regra, a versão e as evidências, estão em Disparos de gatilho.
Próximos passos
Padrões
os sinais que
trait.present pode observar.Webhooks dos seus sistemas
o outro sentido, eventos chegando.
Aproveitamento do contexto
a taxa de repetição por trás de
context_use.repetition_rate.Comprovantes e auditoria
comprovantes entregues ao seu SIEM pelo mesmo mecanismo.

