Atualização de Produto: Melhor UX de Verificação em Massa, Progresso Assíncrono Mais Honesto e um Modelo de Conexão MCP Moderno

Nos últimos ciclos de lançamento, fizemos um conjunto de mudanças que todas apontam na mesma direção: tornar BillionVerify mais fácil de confiar, mais fácil de monitorar e mais fácil de integrar.

Algumas dessas mudanças são imediatamente visíveis no produto. A experiência de Bulk Verify é mais limpa após o envio de arquivo. A página de histórico de verificação é mais útil enquanto um trabalho ainda está em execução. Os indicadores de progresso agora refletem o que os usuários realmente se importam em vez de expor a mecânica interna da fila.

Algumas das mudanças são mais profundas. O contrato de status de verificação atrás da interface é mais rico e mais explícito. O modelo de dados agora distingue entre progresso no nível de email e progresso de execução de backend, o que oferece aos clientes uma base muito melhor para renderizar o estado em tempo real honesto.

E algumas das mudanças afetam os desenvolvedores diretamente. BillionVerify MCP agora se afastou completamente da configuração antiga ?api_key= e entrou em um modelo MCP remoto hospedado construído em torno de OAuth, descoberta de recursos protegidos e compatibilidade com clientes modernos. Atualizamos o produto, a documentação, as páginas de marketing e as superfícies de autenticação para corresponder a essa realidade.

Este post reúne essas atualizações em uma única narrativa para que clientes, desenvolvedores e equipes internas possam ver como se encaixam.

Se você quer a versão curta, aqui está:

• Verificação em massa agora tem um fluxo pós-envio mais limpo.
• Monitoramento de trabalho assíncrono é mais informativo e mais honesto.
• A interface de status de backend está melhor estruturada para trabalho distribuído.
• BillionVerify MCP agora tem uma forma de longo prazo mais clara: endpoint remoto mais OAuth, não chaves de API incorporadas em URL.

Se você quer a história completa, continue lendo.

Links Rápidos

• Verificação de email em massa
• O que é verificação de email?
• Visão geral do MCP
• Guia do desenvolvedor MCP
• Guia do Claude Code
• Referência da API

Por que essas atualizações pertencem juntas

À primeira vista, este lançamento parece ser vários tópicos separados:

• uma limpeza de frontend na página de verificação em massa
• uma tela de histórico mais rica em detalhes
• uma atualização de contrato de status de backend
• uma limpeza de autenticação e documentação de MCP

Mas o tema subjacente é o mesmo em todos eles: remover ambiguidade.

A ambiguidade se manifesta de diferentes formas em produtos de software.

Às vezes parece ser uma UI duplicada após um upload de arquivo. Os usuários não têm certeza de qual botão importa, qual é o melhor próximo passo ou se o sistema ainda está fazendo trabalho em segundo plano.

Às vezes parece uma barra de progresso que diz "29% concluído" enquanto os números ao redor não explicam o que esse percentual representa. É 29% de emails processados? 29% de tarefas de worker concluídas? 29% de resultados mesclados? A maioria dos usuários não quer decodificar arquitetura de fila apenas para monitorar um job.

Às vezes a ambiguidade está na incorporação de desenvolvedores. Um produto pode já suportar uma arquitetura em produção enquanto partes de sua documentação pública ainda sugerem um modelo de conexão mais antigo. Isso cria falhas de configuração, confusão e desconfiança desnecessária.

Este lançamento é nossa resposta para esses problemas.

Apertamos a UX do produto em torno do que os usuários realmente precisam saber. Apertamos as interfaces de backend em torno do que os clientes realmente precisam renderizar. E apertamos a história de MCP voltada para desenvolvedores em torno de como a plataforma realmente funciona hoje.

1. O Bulk Verify agora tem uma experiência pós-upload mais limpa

A primeira parte desta versão se concentrou no momento logo após um arquivo ser enviado.

Esse momento é mais importante do que parece.

Quando alguém envia um grande CSV para verificação, eles não terminaram. Eles acabaram de passar de um estado de entrada para um estado de monitoramento. A interface precisa ajudá-los a responder algumas perguntas imediatas:

• Meu arquivo foi enviado com sucesso?
• O processamento já está em andamento?
• Onde vou para monitorar este trabalho específico?
• Posso confiar que o sistema me notificará quando terminar?

O fluxo anterior respondeu essas perguntas, mas o fez com muita repetição. O cartão de sucesso, o texto de status circundante e os botões disponíveis todos puxavam a atenção em direções ligeiramente diferentes.

Nós limpamos isso.

O que mudou na página

O estado de sucesso do envio agora é mais compacto e mais fácil de examinar. O ícone de sucesso e o título consomem menos espaço vertical, o que dá mais espaço aos detalhes que os usuários realmente se importam: nome do arquivo, contagens de e-mail, tempo de processamento estimado e a próxima ação.

O progresso ao vivo também é exibido por padrão após o envio. Os usuários não precisam mais dar um passo extra para revelar essa informação. Se um trabalho está se movendo, a página deve mostrar isso imediatamente.

O CTA principal pós-envio também mudou de uma maneira importante. Em vez de enviar usuários para o índice de histórico genérico, a ação principal agora vincula diretamente para a página de detalhes exata do trabalho. Isso parece uma pequena mudança, mas remove um salto desnecessário e faz o fluxo de trabalho parecer muito mais deliberado.

Também removemos elementos que eram tecnicamente funcionais, mas não eram significativamente úteis:

• texto de status duplicado na área de upload
• um botão extra "Upload Another File" no cartão de sucesso

Os usuários ainda podem enviar outro arquivo da superfície de upload principal. A diferença é que a interface não compete mais consigo mesma.

Por que isso importa na prática

A verificação em massa é frequentemente usada em fluxos de trabalho repetitivos e operacionais. Os usuários podem enviar vários arquivos por dia, monitorar vários trabalhos em uma sessão de trabalho e retornar mais tarde para baixar resultados filtrados. Nesse tipo de ambiente, até pequenas peças de duplicação de interface se somam.

Limpar o estado pós-upload ajuda de três maneiras:

1. Reduz a quantidade de análise de tela necessária logo após o envio.
2. Torna a próxima etapa óbvia.
3. Mantém a interface alinhada com o modelo mental do usuário: "Meu arquivo está dentro. Agora quero seguir este trabalho."

Este é o tipo de melhoria que raramente faz uma captura de tela chamativa por conta própria, mas faz o produto parecer mais calmo e coerente todos os dias.

Exemplo: o novo caminho pós-envio

Aqui está a jornada pretendida do usuário agora:

1. Envie um CSV no fluxo de verificação em massa.
2. Veja um estado de sucesso imediato com nome do arquivo, contagens de linhas e ETA.
3. Veja progresso ao vivo sem precisar revelá-lo manualmente.
4. Clique em um botão principal para abrir a página de detalhes do histórico exato para esse trabalho.
5. Retorne mais tarde por e-mail ou histórico para revisar resultados e exportações.

Esse é um caminho mais simples do que:

1. Enviar arquivo.
2. Analisar áreas de status duplicadas.
3. Clicar no histórico genérico.
4. Encontrar a linha correta.
5. Reabrir o trabalho de destino.

A redução de esforço é pequena em uma única sessão e significativa com o uso repetido.

2. O histórico de verificação agora se comporta como uma verdadeira superfície de monitoramento

A segunda grande melhoria foi na página de histórico de verificação assíncrona.

Esta página costumava ser funcional, mas superficial. Ela podia mostrar que um trabalho existia e que estava em andamento, mas ainda não se sentia como uma superfície projetada para monitoramento ativo.

Isso é uma incompatibilidade para um trabalho de verificação de longa duração.

Quando um cliente abre uma página de detalhe do histórico enquanto um arquivo ainda está sendo processado, ele não está apenas procurando um número de percentual. Ele está tentando entender:

• a qual arquivo este trabalho se refere
• qual é o tamanho da carga de trabalho
• quanto trabalho já foi concluído
• qual é a mistura de resultados iniciais
• quanto tempo o trabalho provavelmente levará

Reprojetamos a página em torno dessa realidade.

Os metadados estáveis agora aparecem primeiro

A página de histórico atualizada agora começa com um cartão de resumo estável. Esse cartão reúne os metadados de trabalho mais importantes:

• nome do arquivo original
• total de linhas
• contagem de emails únicos
• tempo de processamento estimado
• hora de início

Esta informação não depende do loop de polling em tempo real. Isso importa porque o contexto estável deve aparecer o mais rápido possível, mesmo que o payload de status dinâmico ainda esteja se estabilizando ou atualizando.

Quando os usuários chegam à página, podem se orientar imediatamente, em vez de esperar que uma resposta de status ao vivo faça todo o trabalho.

A área de progresso ao vivo é muito mais rica

Abaixo do resumo, a experiência de estado em execução agora é materialmente melhor.

Em vez de uma barra de progresso simples com contexto limitado, a página agora exibe:

• volume processado
• volume restante
• distribuição de resultados entre status
• semântica de idioma e ETA que correspondem ao fluxo de verificação em massa principal

Tão importante quanto, remove métricas internas que devem permanecer internas. Intencionalmente deixamos de expor contagens de tarefas de trabalho e chunks na superfície voltada para o usuário. Esses valores podem ser operacionalmente úteis, mas não são o que os clientes estão tentando medir quando perguntam: "Quanto tempo meu trabalho levará?"

A pergunta correta é quase sempre centrada em email, não centrada em fila.

As ferramentas de estado concluído permanecem intactas

Uma das restrições de design para este trabalho era que não queríamos perder a profundidade analítica da página de trabalho concluído.

Então mantemos o gráfico de divisão de resultados existente e as ferramentas de exportação. A atualização não foi sobre substituir a experiência de estado concluído. Foi sobre fortalecer o topo da página e tornar a experiência de estado em execução digna do fluxo de trabalho.

Isso significa que a página agora faz ambos os trabalhos melhor:

• durante o processamento, funciona como uma superfície de monitoramento
• após a conclusão, ainda funciona como uma superfície de análise e exportação

Exemplo: o que os usuários agora podem entender em um relance

Uma página de trabalho em execução agora responde rapidamente a todas estas perguntas:

• "Este é o arquivo de 19.293 linhas que enviei anteriormente."
• "Há 19.010 emails únicos nele."
• "O sistema estima aproximadamente 33 minutos."
• "499 emails já foram verificados."
• "A maioria do conjunto concluído até agora é válida, com uma parcela menor inválida e desconhecida."

Esse é um modelo mental muito mais útil do que um único número de percentual com semântica pouco clara.

3. A semântica do progresso agora é mais honesta

Uma das maiores lições em produtos assíncronos é que "progresso" não é um conceito único.

Em um sistema distribuído, existem várias coisas que podem evoluir independentemente:

• tarefas de worker podem ser concluídas
• chunks podem ser mesclados
• resultados em nível de email podem se acumular
• arquivos finais podem ficar disponíveis para download

Se um cliente receber apenas um campo genérico progress, ele tem que adivinhar qual desses significados o número está carregando. É assim que você acaba com estados de UI que são tecnicamente consistentes, mas experiencialmente confusos.

Queríamos corrigir isso no nível de contrato.

A mudança central

A interface atualizada torna possível distinguir entre:

• email_progress
• chunk_progress
• progress_source

Essa distinção oferece aos clientes uma base muito mais forte para renderizar o progresso de forma que corresponda à intenção do usuário.

Por exemplo:

• a grande barra de progresso visível ao usuário agora pode priorizar email_progress
• visualizações operacionais ou de diagnóstico ainda podem usar chunk_progress
• se um fallback for necessário, progress_source pode deixar isso explícito

Este é um modelo muito mais saudável do que fingir que todos os percentuais de progresso significam a mesma coisa.

Exemplo de payload

Aqui está o tipo de estrutura que isso possibilita:

{
  "task_id": "36f68e67-ddcb-441a-a407-22f826e72443",
  "status": "processing",
  "total_emails": 19010,
  "processed_emails": 499,
  "valid_emails": 496,
  "invalid_emails": 2,
  "unknown_emails": 1,
  "catchall_emails": 0,
  "risky_emails": 0,
  "role_emails": 0,
  "disposable_emails": 0,
  "email_progress": 3,
  "chunk_progress": 7,
  "progress_source": "email_progress"
}

Sem nem sequer saber nada sobre o sistema de fila subjacente, um cliente pode tomar boas decisões com essa resposta.

Isso importa porque APIs não apenas retornam dados. Elas definem significado.

Por que isso é melhor para clientes

Clientes não se importam se um worker completou 7 de 96 tarefas internas se apenas 499 dos 19.010 emails foram realmente processados. Expor a abstração de progresso errada cria confusão, não tranquilidade.

Ao orientar a UI principal para email_progress, o produto agora reflete a unidade de trabalho pela qual os usuários realmente se importam.

Por que isso é melhor para equipes frontend

A UI não precisa mais fazer muitas inferências a partir de um único campo de percentual ambíguo.

Isso reduz uma classe inteira de bugs de produto:

• barras de progresso que parecem muito adiantadas
• blocos de resumo que ficam atrás do percentual principal
• texto de status desajeitado que tenta explicar detalhes de implementação de backend para usuários finais

Também oferece às equipes frontend uma forma mais clara de separar metadados de trabalho estáveis de dados de execução em mudança, que leva diretamente à próxima parte da versão.

4. O contrato de status do backend agora está melhor estruturado para trabalho distribuído

As mudanças do frontend não se sustentariam bem sem melhorias no contrato do backend.

Tomamos duas decisões estruturais importantes aqui.

Primeiro, separamos metadados estáveis do status ao vivo

Alguns campos mudam muito pouco, ou não mudam nunca, após a criação de um job:

• nome do arquivo
• horário de criação
• total de linhas
• contagem de emails únicos
• tempo estimado de processamento

Outros campos são inerentemente dinâmicos:

• status atual
• contagem de emails processados
• mix de resultados ao vivo
• percentuais de progresso

Tentar forçar ambas as classes de dados pelo mesmo caminho de polling é uma fonte comum de desconforto na UI. O frontend acaba esperando por dados que deveriam estar disponíveis imediatamente, enquanto também solicita dados estáveis com mais frequência do que necessário.

O novo modelo é mais limpo:

• metadados estáveis do job são tratados como metadados
• status ao vivo do job é tratado como status

Isso soa óbvio quando escrito assim, mas tem efeitos significativos na qualidade da implementação.

A página de detalhe do histórico agora pode renderizar informações de resumo estáveis rapidamente, fazer polling apenas do que precisa mudar, e manter a UI calma enquanto o job é executado.

Segundo, ampliamos o próprio payload de status

A interface de status em tempo real agora é mais adequada para processamento assíncrono distribuído porque carrega uma visão mais rica do que aconteceu até agora.

Isso inclui contadores como:

• processados
• válidos
• inválidos
• desconhecidos
• arriscados
• catch-all
• função
• descartáveis
• créditos usados

Esses valores tornam a interface mais útil não apenas para superfícies de progresso voltadas para humanos, mas também para automação e fluxos de trabalho posteriores. Um cliente que compreende o mix de resultados atual pode tomar decisões melhores sobre alertas, notificações, exportações e pós-processamento.

Exemplo: por que isso importa além da UI

Imagine um app voltado para clientes construído sobre BillionVerify que queira:

• mostrar distribuição de qualidade ao vivo enquanto uma lista está em execução
• notificar um usuário se um job está produzindo uma taxa de inválidos incomumente alta
• oferecer exportações filtradas assim que conjuntos de resultados úteis existirem
• alimentar um dashboard de suporte ou operações sem exigir que a engenharia inspecione o estado bruto do worker

Todos esses casos de uso ficam mais fáceis quando o contrato de status do backend é explícito e rico o suficiente.

É por isso que o trabalho de interface do backend importa mesmo quando a primeira mudança visível é "a barra de progresso ficou melhor." Uma barra de progresso melhor é frequentemente o sintoma de um contrato melhor.

5. MCP agora se mudou completamente para sua era remota OAuth

A última peça principal desta atualização é voltada para desenvolvedores, mas é uma das correções de produto mais importantes a longo prazo no lançamento.

BillionVerify MCP agora está sendo apresentado e documentado na forma que deveria ter para clientes remotos modernos:

• um endpoint remoto hospedado
• autorização baseada em OAuth
• descoberta de recursos protegidos
• acesso padrão com token Bearer

O endpoint é:

https://mcp.billionverify.com/mcp

Isso importa porque padrões de configuração mais antigos podem permanecer em materiais públicos muito tempo depois que uma plataforma já se mudou internamente. No nosso caso, alguns docs e superfícies de marketing ainda sugeriam que MCP poderia ser conectado através de chaves API incorporadas em URL e wrappers curl --stdio.

Essa não é mais a forma correta para BillionVerify MCP.

O modelo mental antigo

O padrão mais antigo era aproximadamente assim:

curl --stdio "https://mcp.billionverify.com/mcp?api_key=YOUR_API_KEY"

Esse modelo une várias preocupações em uma etapa de configuração desajeitada:

• transporte
• autenticação
• manipulação de segredos
• comportamento do wrapper local

Também envia o sinal errado sobre como um servidor MCP remoto hospedado deveria ser consumido por clientes modernos.

O novo modelo mental

O modelo atual é mais limpo.

Para Claude Code, a configuração recomendada é:

claude mcp add --transport http billionverify https://mcp.billionverify.com/mcp

Depois dentro do Claude Code:

/mcp

A partir daí, o cliente completa o fluxo OAuth no navegador.

Para ChatGPT e outros clientes MCP remotos compatíveis, o ponto de partida correto é simplesmente o endpoint:

https://mcp.billionverify.com/mcp

O cliente descobre os metadados de recurso protegido, segue o fluxo de autorização e então usa tokens de acesso Bearer para chamadas autenticadas.

A distinção mais importante: autenticação MCP não é autenticação REST

Uma razão pela qual os docs mais antigos precisavam de limpeza é que as chaves API ainda importam no BillionVerify. Mas não pertencem mais à história de bootstrap do MCP.

A divisão limpa é:

• REST API usa chaves API
• MCP remoto usa OAuth

Essa distinção agora é muito mais clara em toda a superfície do produto.

Se um desenvolvedor está usando:

• ChatGPT
• Claude Code
• outro cliente MCP remoto com capacidade OAuth

ele deve usar o caminho MCP remoto.

Se eles estão construindo:

• automação backend-para-backend
• scripts orientados por chave API
• clientes que suportam apenas stdio local mais chaves API

eles devem usar a referência de API e fluxo REST em vez disso.

Essa não é uma distinção cosmética. É um limite de produto e os docs devem tornar isso óbvio.

6. Documentação pública e marketing agora correspondem ao produto

Uma atualização de arquitetura resolve apenas parte do problema se os materiais públicos ainda contam uma história diferente.

É por isso que tratamos a limpeza de documentação e marketing do MCP como parte da mesma versão.

Atualizamos:

• a página pública do MCP
• o guia do MCP
• o guia do Claude Code
• pontos de entrada do guia de IA
• variantes de documentação multilíngues
• cópia de FAQ de marketing localizada

O objetivo era simples: deveria haver uma resposta clara para a pergunta, "Como conecto BillionVerify MCP?"

Agora há.

Por que isso importa para desenvolvedores

Quando a documentação pública fica atrás da realidade de implementação, os desenvolvedores pagam o preço de três maneiras:

1. Tentativas de configuração falhadas
2. Perda de confiança na plataforma
3. Carga de suporte extra para esclarecer o que deveria ter sido óbvio

Ao alinhar a superfície pública com o modelo OAuth remoto real, reduzimos o atrito desnecessário antes que se torne um problema de suporte.

Por que isso importa para o posicionamento da plataforma

O ecossistema MCP está se movimentando rapidamente. À medida que mais equipes avaliam ferramentas por meio de ChatGPT, Claude Code e outros clientes de IA, a qualidade da primeira experiência de integração importa mais.

Um produto que parece moderno na camada de protocolo, mas desatualizado em sua orientação pública de configuração, cria hesitação justamente onde deveria estar construindo confiança.

É por isso que também fortalecemos as superfícies de entrada e consentimento com Termos mais claros, Privacidade e visibilidade de contato de suporte. Revisores, desenvolvedores e avaliadores empresariais se beneficiam quando os sinais de confiança são explícitos.

7. Uma visão prática antes e depois desta versão

Uma maneira útil de entender a versão é comparar a experiência do usuário e do desenvolvedor antes e depois.

Antes

• Um arquivo de verificação em massa podia ser enviado com sucesso, mas o estado pós-envio ainda tinha UI duplicada e próximos passos menos óbvios.
• A página de detalhes do histórico mostrava atividade, mas ainda não parecia uma superfície de monitoramento completa.
• Um valor de porcentagem concluída podia existir sem informar claramente aos usuários se representava emails processados ou conclusão de tarefas internas.
• Os materiais públicos do MCP ainda refletiam parcialmente uma configuração legada com ?api_key=.

Depois

• A experiência pós-envio é mais limpa, compacta e direta.
• O progresso ao vivo aparece por padrão no fluxo em massa.
• O CTA principal após envio leva os usuários diretamente para a página exata de detalhes do job.
• As páginas de detalhes do histórico mostram metadados de resumo estável mais visibilidade de resultados ao vivo mais rica.
• O progresso visível ao usuário agora se concentra na semântica de progresso em nível de email.
• As contagens de tarefas internas não são mais expostas como métricas visíveis ao cliente.
• A interface de status backend está melhor estruturada para clientes em tempo real e jobs distribuídos.
• Os materiais públicos do MCP agora refletem consistentemente a arquitetura OAuth remota.

Isso não é um único recurso. É uma passagem de qualidade significativa em todo um fluxo de trabalho.

8. O que isso significa para diferentes públicos

Para equipes de operações e crescimento

Você obtém um fluxo de verificação em massa mais suave com menos atrito na UI, melhor visibilidade enquanto os trabalhos estão em execução e acesso mais claro ao trabalho exato que você acabou de iniciar.

Para equipes de produto e frontend

Agora você tem semântica de progresso mais forte e separação mais limpa entre metadados e status ao vivo, o que torna as telas com muito progresso mais fáceis de construir e mais fáceis de explicar.

Para equipes de backend e plataforma

Você tem um contrato de status mais forte para verificação distribuída e uma narrativa mais limpa sobre o que diferentes valores de progresso realmente significam.

Para desenvolvedores integrando MCP

Agora você tem uma resposta muito mais clara para a questão de configuração: use MCP remoto mais OAuth para clientes MCP e use chaves API para a API REST onde esse modelo é apropriado.

9. Por onde começar

Se você deseja explorar a experiência atualizada ou caminhos de integração, comece aqui:

• Saiba mais sobre o produto: Verificação de email
• Execute fluxos de trabalho maiores: Verificação em massa de email
• Entenda os fundamentos: O que é verificação de email?
• Conecte MCP de um cliente suportado: Visão geral de MCP
• Aprofunde-se na configuração: Guia de MCP
• Configure o Claude Code especificamente: Guia do Claude Code
• Use integração baseada em chave de API: Referência de API

Encerramento

Esta versão não foi sobre uma grande mudança superficial. Foi sobre apertar o produto onde a ambiguidade havia se infiltrado.

Tornamos a jornada de verificação em massa mais limpa. Tornamos o monitoramento assíncrono mais útil. Tornamos o relatório de progresso mais preciso. E fizemos a história do MCP corresponder à plataforma que estamos realmente construindo.

Essas melhorias se reforçam mutuamente.

Um produto se torna mais fácil de confiar quando a UI diz menos, mas significa mais. Fica mais fácil de integrar quando a documentação descreve a arquitetura real. E fica mais fácil evoluir quando as interfaces subjacentes à experiência carregam semântica mais clara.

Essa é a direção que continuamos pressionando com BillionVerify.

Se você já está usando BillionVerify, essas mudanças devem tornar seu fluxo de trabalho diário mais direto e mais previsível.

Se você está avaliando a plataforma agora, esta atualização é um bom instantâneo de como pensamos sobre qualidade de produto: clareza visível ao usuário no topo, contratos explícitos abaixo, e documentação que corresponde à realidade.