Cadastro aberto traz usuários errados
Você quer só aprovados, mas o registro aberto deixa entrar abusadores e contas ruins. Checagens manuais demoram e ainda falham.
Aprove exatamente quem pode se cadastrar ou receber e-mails — por endereço ou domínio inteiro. Controle o acesso com um campo `block`, sem lógica de whitelist espalhada.
Sem cartão de crédito. Teste com créditos gratuitos.
para permitir ou negar (`block`)
e-mail exato e domínio inteiro
modo lista de permissões quando a política muda
checagens de política na resposta de verificação
Mantenha apenas usuários e destinatários aprovados nos fluxos, centralizando decisões em uma resposta da API.
Você quer só aprovados, mas o registro aberto deixa entrar abusadores e contas ruins. Checagens manuais demoram e ainda falham.
Cadastro, CRM e campanhas precisam da mesma política, mas cada serviço implementa diferente e diverge.
Quando só alguns clientes devem receber e-mail, listas amplas gastam orçamento e diluem métricas.
Defina uma vez quem pode; depois decida a política com um campo em cada resultado de verificação.
Adicione e-mails exatos como [email protected] ou domínios como company.com para definir quem pode passar.
Ligue quando só e-mails e domínios listados devem passar. Desligue quando regras estritas não forem necessárias.
Use o campo `block` na resposta. `block: true` nega; `block: false` permite.
Exemplo de resposta da API de verificação
GET /v1/[email protected]\nX-API-Key: your-api-key\n\n{\n "valid": true,\n "block": false,\n "domain": "customer.org"\n}E-mail exato
Permitir um endereço específico quando só usuários selecionados devem passar.
Domínio
Permitir todas as caixas em domínios aprovados como partner.com ou customer.org.
Equipes reais protegem onboarding, afinam campanhas e tiram lógica de política do código.
Founder, B2B SaaS
“Ativamos a lista para trials enterprise e paramos cadastros aleatórios. Vendas fala só com contas que miramos.”
Lifecycle Marketing Lead
“Em campanhas só parceiros, listamos domínios aprovados e evitamos o público errado. Menos envios desperdiçados.”
Product Manager, Marketplace
“Antes tínhamos allow em vários serviços. Agora cada fluxo lê o mesmo `block` de forma consistente.”
O campo `block` na resposta de verificação. Se `block` for true, negue; se false, permita.
Sim. Adicione endereços precisos ou domínios como `company.com` para permitir todas as caixas desse domínio.
Sim. O modo pode ser ativado ou desativado para exigir só permitidos apenas quando o fluxo precisar.
Sim. Gerencie regras uma vez e leia `block` da API em vez de duplicar matching em vários backends.
A lista de bloqueio tem prioridade. Se a blacklist casar, `block` continua true mesmo com whitelist.