Esta página reúne as proteções que o Data Lead aplica sozinho e as que dependem de uma escolha sua. Nada aqui substitui o resumo do acordo de tratamento de dados — peça-o ao suporte se o seu jurídico precisar da lista de subprocessadores.
Anti-bot no primeiro envio
A primeira mensagem de cada conversa pode passar por um desafio invisível (Cloudflare Turnstile). Ele é carregado sob demanda, só quando o visitante vai enviar — nunca no carregamento da página —, para não pesar no site nem avisar um terceiro sobre quem apenas visitou.
Regras que valem sempre:
- O anti-bot nunca é o motivo de alguém não conseguir falar. Se a Cloudflare estiver fora do ar, bloqueada por CSP ou por um bloqueador de anúncios, ou se o desafio demorar mais de 2,5 segundos, o envio segue sem token.
- Só o primeiro turno é desafiado. Os turnos seguintes já estão presos ao token daquela conversa.
- Um token inválido é recusado com o erro
403 turnstile_required, e o widget refaz o desafio e reenvia a mesma mensagem — o visitante não deveria nem perceber.
O desafio depende de configuração da plataforma: pode não estar habilitado na sua conta; fale com o suporte se precisar ligá-lo.
Tokens: quatro tipos, quatro comportamentos
| Token | Para que serve | Como é guardado |
|---|---|---|
Token da API (dl_…) |
Ler leads, conversas, playbooks, uso e webhooks de fora do painel | Aparece uma única vez, na criação. O banco guarda só um resumo criptográfico. Perdeu, gere outro e revogue o antigo. |
| Token do visitante | Autoriza os turnos de uma conversa do widget | Vive no navegador do visitante, expira em 15 minutos e não dá acesso a nada do painel |
| Link de convite | Deixa alguém entrar na sua equipe | Vale 7 dias, é consumido uma única vez e o banco guarda só o resumo criptográfico dele |
Segredo do webhook (whsec_…) |
Assinar cada entrega para você conferir a origem | Mostrado uma vez, na criação do endpoint |
Recomendações para o token da API:
- guarde-o em um cofre de segredos, nunca no código versionado nem no navegador;
- crie somente leitura por padrão; escolha leitura e escrita apenas quando a integração precisar alterar o estágio ou o dono de um lead;
- um token por integração, com nome que diga qual é ("Integração com o ERP"), para revogar sem derrubar as outras;
- revogar é irreversível e vale na hora: "Quem usa este token perde o acesso à API na hora, e não há como reativá-lo."
Credenciais de integração ficam cifradas
Tokens de CRM, credenciais de mídia paga, o acesso à agenda do vendedor e o segredo de cada webhook são guardados cifrados em repouso (AES-256-GCM). A chave vive apenas no ambiente de execução: nem a sessão do painel enxerga essas colunas.
Webhooks têm duas proteções a mais, porque a chamada parte do nosso servidor:
- redirecionamentos não são seguidos e endereços internos (
localhost, faixas privadas,.internal) são recusados no cadastro e a cada entrega; - dez falhas consecutivas desativam o endpoint, e o dono da conta recebe um aviso por e-mail. Reative em Integrações depois de consertar o destino.
Isolamento e limites
- Isolamento por conta no banco: cada consulta é recortada pela conta de quem está autenticado, com segurança em nível de linha. As operações que atravessam esse isolamento (busca, exportação e exclusão de titular) exigem chamador de confiança.
- IP truncado na borda: o endereço do visitante nunca chega inteiro ao banco. O registro de consentimento guarda a forma truncada.
- Freios de tráfego nas rotas públicas do widget, por conversa, por site e por IP, e na API
pública (120 requisições por minuto por token, 240 por IP), com resposta
429eRetry-After. - Contatos mascarados na API: quem lê leads por token recebe
jo***@dominio.com.bre(11) 9****-0000. O contato completo sai pela exportação em CSV da tela de Leads, que exige sessão de uma pessoa.
O que nunca vai para log
Esta é uma regra do produto, não uma preferência: nenhum log carrega e-mail, telefone, chave do site, token, segredo de integração ou o valor digitado num pedido de titular.
O que os registros guardam é o suficiente para investigar sem virar uma segunda cópia do dado:
- a trilha de auditoria guarda quem acessou dado de pessoa, quando e sobre quem — com o identificador sempre mascarado;
- o registro de um pedido de titular guarda tipo, máscara, contagens afetadas e quem atendeu, nunca o valor do titular;
- o log de entrega das integrações guarda status, duração e o erro truncado, sem dado pessoal;
- os eventos de navegação saem com a URL limpa: parâmetros de campanha, identificadores de
clique e chaves como
email,phone,cpf,cnpjetokensão removidos da URL e do referenciador antes do envio, em qualquer modo de consentimento — eles não somem, mudam de lugar: viajam em campos próprios do evento (a campanha sempre, os identificadores de clique só com consentimento), nunca dentro da URL nem do referenciador.
O que não fazemos
- Não vendemos dado pessoal nem o cedemos para publicidade de terceiros.
- Não usamos o dado de um cliente para treinar nada — nem modelo próprio, nem o agente de outro cliente.
- Não mostramos dado pessoal de terceiro ao visitante.
- Não tomamos decisão automatizada com efeito jurídico sobre a pessoa: o assistente qualifica e encaminha; quem decide é gente.
- Não rastreamos entre sites de clientes diferentes: o identificador do visitante é por site.
Se algo parecer errado
Suspeita de token vazado: revogue primeiro, investigue depois — a lista mostra quando cada token foi criado e quando foi usado pela última vez. Suspeita de acesso indevido a dado de pessoa: abra Configurações → Direitos do titular e leia a trilha de auditoria. Em qualquer incidente confirmado, avise o suporte da Data Stone.
Veja também
Precisa de ajuda?
Fale com o suporte da Data Stone pelo canal combinado com a sua conta. Em suspeita de vazamento de token, revogue o token antes de abrir o chamado.