Pular para o conteúdo principal
A Niadra avisa os seus sistemas quando algo acontece na memória, por webhooks assinados. Há dois tipos. Uma assinatura de webhook entrega cada ocorrência de um tipo de evento, como 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.present que nomeia um padrão desligado ou que não existe;
  • uma regra context_use.repetition_rate com parâmetros que a varredura não consegue ler ou com uma source_id que 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.
Só conta o que o diff introduz: um problema que já estava gravado não bloqueia outra mudança. Desligar um endpoint é uma escolha, e as regras dele esperam que ele volte. Cortar a fonte dona de endpoints, de fluxos de SIEM ou de um mapeamento funciona sempre: as chaves param na hora, e esses objetos saem junto com ela da configuração da célula (as entregas pendentes terminam com 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, assine conversation.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.silent observa 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_rate lê a medição diária de Aproveitamento do contexto. Dispara quando, nos últimos window_days dias (7 por padrão, até 90), as perguntas repetidas passam da fração above (0,2 por padrão) das perguntas da fonte, com pelo menos min_questions perguntas (30 por padrão) para o número valer. Sem source_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 em data.detail as 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), e links.open aponta para /v1/context-use?source_id=.... Parâmetros que a varredura não consegue ler, ou uma source_id que não existe no espaço, são recusados quando o diff é enviado e quando é aprovado.
Antes de ligar uma regra, rode um teste a seco por POST /v1/triggers/dry-run: a regra em teste traz rule_id, condition, params, o endpoint_id de destino, window_hours (24 por padrão, até 90 dias) e late_policy (deliver_marked ou suppress). A resposta diz para quantos dos clientes ativos nos últimos 30 dias (subjects_evaluated) a condição vale agora (would_fire), com uma amostra de até 10, e traz target_problem quando a fonte do endpoint não pode ler o conteúdo do aviso. Para source.silent e context_use.repetition_rate, o teste avalia as fontes do espaço como a varredura as veria agora. O teste confere a condição; a janela e a deduplicação só valem nos disparos de verdade, e nada é disparado. Ajuste os parâmetros antes de acionar qualquer pessoa. Pede o papel integration ou uma chave admin.
Exemplo: “avisar o CRM um dia depois de uma visita técnica perdida”. Quando a visita remarcada da Marina passa um dia do prazo sem ação que a feche, a Niadra manda 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.
O corpo leva ids, a regra e a versão, estado e ponteiros para as evidências. Nunca leva conteúdo de conversa. O sujeito é o pseudônimo e o tipo do cliente, nunca telefone, e-mail ou número de documento. 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 por PUT /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_of e 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 por GET /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 fica pending, 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.