Aceite de Termos via API (Clickwrap): A Receita Completa com Evidências
Todo SaaS tem um checkbox "li e aceito os termos" — e quase nenhum tem prova desse aceite que sobreviva a uma disputa. Um boolean no seu banco é evidência que você fabrica e guarda: fácil de contestar, impossível de verificar por terceiros. Este guia mostra a receita do clickwrap com lastro: o mesmo clique de sempre para o usuário, mas sobre um documento com hash, numa sessão com trilha de auditoria e pacote de evidências — via CLICK_ONLY, o perfil de menor fricção da API.
O problema do checkbox caseiro
Quando o aceite é um campo accepted_terms_at na sua tabela de usuários, três ataques o derrubam numa disputa: "nunca vi esses termos" (você não prova a exibição), "o texto era outro" (você não prova a versão) e "esse registro foi criado depois" (você não prova a data — o log é seu). O clickwrap via plataforma responde aos três: o documento exato tem hash SHA-256, a sessão registra data/hora, IP, geolocalização e user-agent num sistema de terceiro, e o resultado é um pacote de evidências (.p7m) verificável de forma independente. A régua jurídica completa está em níveis de assinatura da Lei 14.063 — o clickwrap é o degrau de entrada, e para termos de uso ele é o padrão do mercado.
A receita: uma chamada, um clique, uma evidência
O perfil CLICK_ONLY executa uma única etapa (CLICK_ACCEPT) — sem OTP, sem biometria. A sessão nasce com o PDF dos termos e o usuário:
Três detalhes fazem diferença: o X-Idempotency-Key por usuário+versão evita sessões duplicadas no retry; o userExternalId amarra o aceite ao seu ID interno; e o returnUrl devolve o usuário ao seu onboarding após o aceite. O link final é url?cs=clientSecret.
A regra de ouro: sem OTP, o link É a autenticação
CLICK_ONLY não há segundo fator — quem tem o link conclui o aceite. A evidência de identidade é a posse do link. Portanto, entregue-o somente por um canal que já autenticou o usuário: dentro da sessão logada do seu app (o ideal — abra o checkout em pop-up com a biblioteca @signdocs-brasil/js) ou no e-mail verificado da conta. Nunca em página pública, nunca em canal compartilhado. Se você não tem um canal autenticado confiável para a entrega, o desenho certo é CLICK_PLUS_OTP — o código por e-mail/SMS assume o papel de autenticação, ao custo de um passo a mais.
Essa lógica também define a escada de upgrade: termos de uso e políticas ficam no CLICK_ONLY; aceites que movimentam dinheiro ou criam obrigação relevante sobem para CLICK_PLUS_OTP; e contratos de alto risco vão de biometria com prova de vida a certificado ICP-Brasil — mudando apenas o policy.profile, com o resto do seu código intacto.
Fechando o loop: webhook, download, versionamento
O webhook de conclusão
Ao concluir, seu endpoint recebe SIGNING_SESSION.COMPLETED (assinado com HMAC-SHA256 — verifique antes de processar). É o gatilho para marcar o aceite no seu domínio, liberar o onboarding e arquivar: GET /v1/transactions/{id}/download para o PDF aceito, /evidence para o .p7m. O receptor completo está em webhooks e eventos.
Versionamento dos termos
Cada versão dos termos é um PDF imutável (Termos_de_Uso_v2026-08.pdf). O hash na trilha amarra cada aceite à versão exata — a defesa "o texto era outro" morre aqui. Quando os termos mudarem: novo PDF, sessões de re-aceite disparadas em lote pela API para a base ativa, e o histórico de cada usuário acumula um aceite por versão, cada um com seu transactionId no seu banco.
Aparência da página
O objeto appearance na criação (nome da empresa, logotipo, cores) faz a página hospedada parecer parte do seu produto — por envio, o que atende também cenários white-label em que cada cliente seu vê a própria marca.
Onde isso se aplica
- Onboarding de SaaS: termos de uso + política de privacidade no cadastro, sem quebrar a conversão.
- Marketplaces: termo de adesão do vendedor antes da primeira venda — veja e-commerce e marketplaces.
- Fintechs: termos de abertura de conta no nível certo — e upgrade de perfil para as operações que pedem mais, em fintechs e bancos digitais.
- Atualização de contrato em massa: re-aceite versionado para toda a base, com evidência individual por usuário.
Perguntas Frequentes
Um checkbox 'li e aceito' no meu app já não basta?
Juridicamente pode valer — o problema é a prova. Um boolean no seu banco de dados é uma evidência que você mesmo fabrica e você mesmo guarda: numa disputa, a outra parte alega que nunca viu os termos, que a versão era outra ou que o registro foi criado depois. O clickwrap via API resolve exatamente isso: o aceite acontece sobre um documento com hash SHA-256, numa sessão com trilha de auditoria (data/hora, IP, geolocalização, user-agent) gerada por um terceiro, com pacote de evidências verificável de forma independente. O gesto do usuário continua sendo um clique; o que muda é o lastro.
Clickwrap tem validade jurídica no Brasil?
Sim, para a maioria dos documentos. O clickwrap é uma assinatura eletrônica no sentido da Lei 14.063/2020 e da MP 2.200-2/2001 (art. 10, §2º): vale o meio que comprove autoria e integridade, aceito pelas partes. Para termos de uso, políticas de privacidade e aceites de baixo risco, é amplamente aceito e é o padrão do mercado. A força probatória cresce com a evidência em volta do clique — e é por isso que o clique 'de plataforma', com trilha e hash, vale mais que o checkbox caseiro. Para contratos de maior valor, o mesmo fluxo aceita subir o nível: OTP, biometria ou certificado ICP-Brasil, mudando apenas o policy.profile.
Como funciona o CLICK_ONLY na prática?
Uma chamada a POST /v1/signing-sessions com policy.profile CLICK_ONLY, o signatário e o PDF dos termos em base64. A resposta traz a url da página hospedada e o clientSecret — o link final é url?cs=.... O usuário abre, lê o documento e conclui com o aceite; internamente o perfil executa uma única etapa (CLICK_ACCEPT). Seu backend recebe o webhook SIGNING_SESSION.COMPLETED, baixa o documento e o pacote de evidências e marca o aceite no seu domínio. Sem OTP, sem biometria — fricção mínima, evidência máxima para o nível.
Como entrego o link com segurança, já que não há OTP?
Essa é a regra de ouro do CLICK_ONLY: sem um segundo fator, o link É a autenticação — quem tem o link conclui o aceite. Por isso, entregue-o apenas por um canal que já autenticou o usuário: dentro da sessão logada do seu app (abra o checkout em pop-up com a biblioteca @signdocs-brasil/js), ou no e-mail verificado da conta. Nunca publique o link em página aberta nem o envie a canais compartilhados. Se o seu fluxo não tem canal autenticado confiável, essa é a deixa para usar CLICK_PLUS_OTP — o código por e-mail/SMS passa a fazer o papel de autenticação.
Como gerencio versões dos termos de uso?
Trate cada versão dos termos como um documento imutável: gere o PDF da versão (v2026-08, por exemplo), crie uma sessão por usuário sobre esse PDF e guarde o transactionId junto ao registro de aceite no seu banco. O hash SHA-256 do documento na trilha de evidências amarra o aceite àquela versão exata — ninguém discute 'qual texto valia'. Quando os termos mudarem, novo PDF, novas sessões de re-aceite para a base ativa (dispare em lote pela API) e o histórico de cada usuário fica com um aceite por versão.
Isso consome minha cota como qualquer documento?
Sim — cada sessão de aceite é uma transação como outra qualquer, com documento, trilha e evidências. Para o dimensionamento: aceites de termos costumam ter volume maior e valor unitário menor que contratos, então esse número entra na conversa do plano sob medida com o time comercial. No desenvolvimento, o sandbox de homologação é gratuito e ilimitado — modele o fluxo de re-aceite em massa lá antes de estimar o volume de produção.
Troque o checkbox por evidência — em uma tarde
Crie credenciais de homologação, suba o PDF dos seus termos e colete o primeiro aceite com trilha completa no sandbox gratuito. O volume de produção se dimensiona depois, com o time comercial.
Criar credenciais de homologação Falar com o time comercial