Para empresas que querem crescer com controle

Um sistema para operar sua empresa com IA.

Vendas, marketing, atendimento, operação, financeiro e inteligência trabalhando sobre o mesmo contexto — para sua empresa ganhar escala sem perder controle.

Sua empresa inteira. Uma operação. IA trabalhando.

Ver a Centriu funcionando

Para empresas de qualquer setor que querem crescer com estrutura, controle e inteligência.

Representação ilustrativa do trabalho em execução

O problema

Sua empresa não deveria operar em pedaços

Não é falta de ferramenta. É que cada ferramenta resolve um pedaço, e ninguém é dono do todo. O custo disso não aparece numa fatura — aparece no mês seguinte.

Sistemas que não se falam
O mesmo dado é digitado de novo — e cada cópia conta uma história diferente.
Dados duplicados
Ninguém sabe qual versão é a verdadeira na hora de decidir.
Conversas perdidas
O cliente repete o contexto a cada canal e a cada pessoa.
Tarefas espalhadas
O trabalho vive em planilhas, mensagens e na memória de alguém.
Decisões sem contexto
A escolha é feita com o recorte que estava à mão, não com o que importava.
Automações desconectadas
Cada ferramenta automatiza um pedaço e ninguém enxerga o todo.

Nenhum desses problemas se resolve comprando mais um software. Eles se resolvem quando a operação inteira passa a trabalhar sobre o mesmo contexto.

A resposta

Tudo trabalha sobre o mesmo contexto.

A Centriu não é uma coleção de produtos. É uma plataforma em que clientes, áreas e agentes leem e escrevem no mesmo lugar.

Cliente 360

Um contexto, não vários cadastros

Cada conversa, tarefa, campanha, cobrança e decisão fica ligada ao cliente e à operação — não a um sistema isolado.

Clientes
Comercial
Atendimento
Operação
Financeiro
Marketing
Inteligência
Agentes
Consultoria

As áreas abaixo são partes da mesma operação, não produtos separados. Elas compartilham conta, permissões e histórico.

IA que trabalha — não um chatbot ao lado

A inteligência artificial da Centriu participa da operação: entende contexto, prepara trabalho, executa rotinas e pede aprovação quando importa.

Entende o contexto

Lê a operação, o cliente e o histórico antes de propor qualquer coisa.

Prepara o trabalho

Redige, organiza, calcula e deixa pronto para revisão humana.

Executa rotinas

Roda o que é repetitivo dentro dos limites definidos pela empresa.

Recomenda a próxima ação

Cruza áreas, identifica prioridade e mostra o motivo da recomendação.

Pede aprovação

O que é sensível passa por uma pessoa antes de valer. Sem exceção silenciosa.

Mantém histórico e aprende

Registra o que aconteceu e usa o resultado para melhorar a próxima decisão.

O que a Centriu faz

Uma plataforma, várias frentes de trabalho. Tudo no mesmo contexto, com a IA participando do que dá para acelerar.

Comercial

CRM, pipeline, oportunidades, propostas, follow-up e automações.

Atendimento

WhatsApp, Instagram, Messenger, chat do site e e-mail no mesmo contexto.

Operação

Tarefas, responsáveis, prazos, aprovações, agenda e capacidade.

Financeiro

Contas, cobranças, caixa, fiscal, margem, IR, orçamento e inteligência econômica.

Marketing

Planejar, produzir, aprovar, publicar e medir conteúdo e campanhas.

Inteligência

Painéis, alertas, previsões, recomendações e leitura executiva.

Agentes

Rotinas executadas continuamente pela IA com controle e aprovação.

Consultoria

Diagnóstico, estratégia, transformação, acompanhamento e especialistas.

Para quem é

Para empresas que querem crescer — e crescer certo.

A Centriu faz sentido quando o volume aumenta e a estrutura precisa acompanhar. Não é sobre setor nem tamanho: é sobre a operação conseguir sustentar o próximo estágio.

As vendas crescem, mas o processo não acompanha.

As áreas trabalham separadas e o cliente sente.

A operação depende de pessoas específicas.

O financeiro ficou complexo e o caixa perde visibilidade.

O atendimento cresce em volume e em canais.

A IA entra sem contexto, controle ou histórico.

Se a empresa ainda não começou a crescer, a Centriu também ajuda a preparar a estrutura para o primeiro salto.

Ver a Centriu funcionando

Consultoria

Tecnologia sozinha não resolve uma operação mal desenhada.

A Centriu combina tecnologia, inteligência, método e acompanhamento. A consultoria diagnostica, desenha, implanta e acompanha — com evidências, não com apresentação.

Diagnóstico e imersão na operação

Estratégia e prioridades

Roadmap de transformação

Desenho da arquitetura operacional

Implantação conduzida

Acompanhamento com evidências

Benchmarking e leitura de mercado

Especialistas, rede e inteligência coletiva

A participação de especialistas depende da solução e do contrato. Não é um item incluído automaticamente em toda contratação, e não prometemos acompanhamento humano ilimitado.

Veja a Centriu funcionando na sua operação

Uma conversa para entender onde a sua operação perde tempo, dinheiro ou capacidade — e o que a Centriu faria primeiro.

Ver a Centriu funcionando

problema

Segurança do Webhook do Agente de WhatsApp: a Porta Fechada de Dentro, Não no Portão

Um webhook que recebe eventos de um servidor externo tem um problema estrutural: o portão de autenticação padrão de uma plataforma normalmente exige um token que aquele servidor externo não tem e não deveria ter. Desligar o portão inteiro para resolver isso abriria a porta para qualquer um forjar um evento. O Centriu Axis resolve isso fechando a porta DENTRO da própria função: todo evento recebido precisa vir acompanhado de uma assinatura HMAC-SHA256 calculada sobre o corpo bruto da requisição com uma chave secreta compartilhada — e a ausência do segredo nunca é tratada como autorização por padrão, exatamente o oposto do que aconteceria se a verificação falhasse aberta.

Quero resolver isso

O problema estrutural de todo webhook de servidor externo

Um agente de atendimento por WhatsApp dentro do Centriu Axis depende de um servidor de conexão (o servidor Baileys, hospedado à parte) que avisa a aplicação sempre que uma mensagem nova chega, uma conexão cai, ou um QR Code de pareamento precisa ser exibido. Esse aviso chega como uma chamada HTTP comum — um webhook. E aqui mora a tensão: o mecanismo de autenticação padrão de qualquer função exposta na plataforma normalmente exige um token de sessão de usuário, e o servidor Baileys não tem, nem deveria ter, um token desses. Ele não é um usuário logado — é um processo de infraestrutura chamando de volta.

A solução ingênua — desligar a exigência de token só para esse endpoint — resolveria o sintoma (o aviso passa a entrar) e criaria um problema maior: sem NENHUMA verificação, qualquer requisição de qualquer origem poderia se passar por um evento real do servidor de WhatsApp e fazer o agente responder a um número escolhido por quem forjou a chamada.

Um agente de atendimento por WhatsApp dentro do Centriu Axis depende de um servidor de conexão (o servidor Baileys, hospedado à parte) que avisa a aplicação sempre que uma mensagem nova chega, uma conexão cai, ou um QR Code de pareamento precisa ser exibido. Esse aviso chega como uma chamada HTTP comum — um webhook. E aqui mora a tensão: o mecanismo de autenticação padrão de qualquer função exposta na plataforma normalmente exige um token de sessão de usuário, e o servidor Baileys não tem, nem deveria ter, um token desses. Ele não é um usuário logado — é um processo de infraestrutura chamando de volta.
A solução ingênua — desligar a exigência de token só para esse endpoint — resolveria o sintoma (o aviso passa a entrar) e criaria um problema maior: sem NENHUMA verificação, qualquer requisição de qualquer origem poderia se passar por um evento real do servidor de WhatsApp e fazer o agente responder a um número escolhido por quem forjou a chamada.

Quero resolver isso

Como o Centriu Axis fecha a porta: assinatura HMAC do corpo bruto, fail-closed

A função que recebe o webhook do agente de WhatsApp roda sem a exigência do token de sessão padrão — necessário, porque o servidor externo não tem esse token — mas isso só é seguro porque a autenticação de fato acontece dentro do próprio código, por um contrato que o servidor de conexão já assina desde antes: cada requisição chega com um cabeçalho de assinatura (`x-link-signature`), calculado como HMAC-SHA256 do corpo CRU da requisição usando uma chave secreta compartilhada. A função lê o corpo como texto puro, antes de qualquer interpretação como JSON — assinar o JSON já reprocessado falharia, porque ordem de chaves e espaçamento não sobrevivem ao reprocessamento — e só então confere a assinatura recebida contra a calculada.

O ponto que faz esse desenho realmente seguro é o comportamento em caso de dúvida: a função de conferência devolve verdadeiro só quando o segredo está presente E a assinatura bate — nunca quando o segredo está ausente. Isso significa que uma variável de ambiente que sumisse silenciosamente num deploy não abriria o endpoint por omissão; ela o manteria fechado. As ações disparadas pela tela (não pelo webhook) continuam exigindo, separadamente, um token de sessão de usuário real e verificação de que essa pessoa pertence à equipe daquela agência.

Ver como funciona

O que está de fato implementado e provado

Verificação de assinatura HMAC-SHA256 sobre o corpo bruto da requisição, com o mesmo contrato já usado por outras integrações do mesmo servidor de conexão.
Leitura do corpo como texto antes de qualquer interpretação, para a assinatura ser calculada sobre exatamente os bytes recebidos.
Comportamento fail-closed: segredo ausente nunca resulta em autorização concedida.
Separação entre autenticação do webhook (assinatura HMAC) e autenticação das ações de tela (token de sessão de usuário + verificação de equipe).
Ignora silenciosamente, sem erro registrado, eventos de instâncias que não pertencem ao próprio módulo — reduzindo ruído de log sem abrir mão da verificação de assinatura.

Conhecer os recursos

O que muda na postura de segurança

A mudança estrutural é que a superfície exposta publicamente deixa de depender de um único portão genérico — que nem se aplicaria corretamente a um servidor sem sessão de usuário — e passa a ter uma verificação própria, desenhada para o formato exato dessa integração, com um padrão de falha que fecha por padrão em vez de abrir por padrão. Isso não é uma métrica que se meça em porcentagem; é uma propriedade estrutural do endpoint: ele nunca aceita um evento sem prova de origem.

A mudança estrutural é que a superfície exposta publicamente deixa de depender de um único portão genérico — que nem se aplicaria corretamente a um servidor sem sessão de usuário — e passa a ter uma verificação própria, desenhada para o formato exato dessa integração, com um padrão de falha que fecha por padrão em vez de abrir por padrão. Isso não é uma métrica que se meça em porcentagem; é uma propriedade estrutural do endpoint: ele nunca aceita um evento sem prova de origem.

Quero esses resultados

Os quatro estados reais testados (não um cenário hipotético)

A correção foi verificada nos quatro estados possíveis de uma requisição chegando a esse endpoint: sem nenhuma assinatura, a resposta é recusa com aviso explícito de assinatura inválida. Com uma assinatura incorreta — calculada com a chave errada ou sobre um corpo alterado — o resultado é o mesmo, recusa. Com uma assinatura válida vinda de uma instância de outro módulo que também usa o mesmo servidor de conexão, o evento é aceito mas silenciosamente ignorado, porque não pertence ao agente de WhatsApp do Axis. E uma tentativa de acionar uma ação de tela sem um token de sessão de usuário válido é recusada por um motivo diferente — sessão ausente ou expirada — confirmando que os dois mecanismos de autenticação (webhook e tela) são de fato independentes e ambos ativos.

Conversar sobre meu caso

Como começar

Começar agora

Perguntas frequentes

Por que esse webhook não usa o mesmo token de sessão das outras funções do Axis?

Porque quem chama esse endpoint é um servidor de infraestrutura (o servidor de conexão do WhatsApp), não um usuário logado — ele nunca teria um token de sessão para apresentar. A autenticação acontece por outro mecanismo: assinatura HMAC do corpo da requisição.

O que acontece se a variável de ambiente com o segredo de assinatura sumir num deploy?

A função de conferência de assinatura devolve falso quando o segredo está ausente — nunca verdadeiro por omissão. Um segredo ausente fecha o endpoint, não o abre.

Qualquer um pode mandar uma requisição forjada para esse webhook?

Só passaria pela verificação quem tiver o segredo compartilhado e calcular corretamente a assinatura HMAC-SHA256 sobre o corpo exato da requisição — sem o segredo, a assinatura não tem como bater.

Isso foi testado de verdade ou é só o desenho pretendido?

Foi verificado nos quatro estados possíveis após a correção: sem assinatura (recusado), assinatura errada (recusado), assinatura válida de instância de outro módulo (aceito e ignorado silenciosamente, por não pertencer a este agente) e ação de tela sem sessão válida (recusada por motivo separado).

Esse mecanismo é exclusivo do Axis?

O contrato de assinatura (mesmo cabeçalho, mesmo algoritmo) já era usado por outras integrações que dependem do mesmo servidor de conexão — o Axis reaproveitou o contrato existente em vez de inventar um novo.

Ainda tenho dúvida

Entender a segurança do agente de WhatsApp do Centriu Axis

Quero resolver isso