Durante el último ciclo de lanzamiento, realizamos una serie de cambios que apuntan todos en la misma dirección: hacer que BillionVerify sea más fácil de confiar, más fácil de monitorear e integrar.
Algunos de esos cambios son inmediatamente visibles en el producto. La experiencia de Verificación en Lote es más limpia después del envío de archivos. La página de historial de verificación es más útil mientras un trabajo aún se ejecuta. Los indicadores de progreso ahora reflejan lo que los usuarios realmente les importa en lugar de exponer la mecánica interna de la cola.
Algunos de los cambios son más profundos. El contrato de estado de verificación detrás de la UI es más rico y explícito. El modelo de datos ahora distingue entre el progreso a nivel de correo electrónico y el progreso de ejecución del backend, lo que proporciona a los clientes una base mucho mejor para representar un estado realtime honesto.
Y algunos de los cambios afectan directamente a los desarrolladores. BillionVerify MCP ahora se ha alejado completamente de la configuración antigua ?api_key= y se ha trasladado a un modelo MCP remoto alojado construido alrededor de OAuth, descubrimiento de recursos protegidos y compatibilidad moderna del cliente. Actualizamos el producto, la documentación, las páginas de marketing y las superficies de autenticación para que coincidan con esa realidad.
Este artículo reúne esas actualizaciones en una sola narrativa para que clientes, desarrolladores y equipos internos puedan ver cómo encajan.
Si quieres la versión corta, aquí está:
- La verificación en lote ahora tiene un flujo posterior al envío más limpio.
- El monitoreo de trabajos asincrónico es más informativo y más honesto.
- La interfaz de estado del backend está mejor estructurada para el trabajo distribuido.
- BillionVerify MCP ahora tiene una forma a largo plazo más clara: punto final remoto más OAuth, no claves API incrustadas en la URL.
Si quieres la historia completa, continúa leyendo.
Enlaces Rápidos
- Verificación de correo electrónico en lote
- ¿Qué es la verificación de correo electrónico?
- Descripción general de MCP
- Guía para desarrolladores de MCP
- Guía de Claude Code
- Referencia de API
Por qué estas actualizaciones van juntas
A primera vista, esta versión parece varios hilos separados:
- una limpieza de frontend en la página de verificación en lote
- una pantalla de historial más detallada
- una actualización del contrato de estado del backend
- una limpieza de autenticación y documentación de MCP
Pero el tema subyacente es el mismo en todos ellos: eliminar la ambigüedad.
La ambigüedad se presenta de diferentes maneras en los productos de software.
A veces se ve como interfaz de usuario duplicada después de una carga de archivo. Los usuarios no están seguros de qué botón importa, cuál es el mejor siguiente paso o si el sistema sigue trabajando en segundo plano.
A veces se ve como una barra de progreso que dice "29% completado" mientras que los números circundantes no explican qué representa ese porcentaje. ¿Es el 29% de correos electrónicos procesados? ¿29% de tareas de worker completadas? ¿29% de resultados fusionados? La mayoría de los usuarios no quieren decodificar la arquitectura de cola solo para monitorear un trabajo.
A veces la ambigüedad está en la incorporación de desarrolladores. Un producto ya puede soportar una arquitectura en producción mientras que partes de su documentación pública aún sugieren un modelo de conexión más antiguo. Eso crea fallas en la configuración, confusión e desconfianza innecesaria.
Esta versión es nuestra respuesta a esos problemas.
Ajustamos la UX del producto en torno a lo que los usuarios realmente necesitan saber. Ajustamos las interfaces del backend en torno a lo que los clientes realmente necesitan renderizar. Y ajustamos la historia de MCP orientada a desarrolladores en torno a cómo funciona realmente la plataforma hoy.
1. Bulk Verify ahora tiene una experiencia post-carga más limpia
La primera parte de esta versión se enfocó en el momento justo después de que se envía un archivo.
Ese momento importa más de lo que parece.
Cuando alguien carga un CSV grande para verificación, no ha terminado. Acaba de pasar de un estado de entrada a un estado de monitoreo. La interfaz debe ayudarles a responder algunas preguntas inmediatas:
- ¿Se envió mi archivo correctamente?
- ¿Ya está en curso el procesamiento?
- ¿Dónde voy para monitorear este trabajo específico?
- ¿Puedo confiar en que el sistema me notificará cuando termine?
El flujo anterior respondía esas preguntas, pero lo hacía con demasiada repetición. La tarjeta de éxito, el texto de estado circundante y los botones disponibles llamaban la atención en direcciones ligeramente diferentes.
Limpiamos eso.
Qué cambió en la página
El estado de éxito de envío ahora es más compacto y fácil de escanear. El icono de éxito y el título ocupan menos espacio vertical, lo que da más espacio a los detalles que realmente importan a los usuarios: nombre del archivo, conteos de correos electrónicos, tiempo de procesamiento estimado y la siguiente acción.
El progreso en vivo también se muestra por defecto después del envío. Los usuarios ya no tienen que dar un paso extra para revelar esa información. Si un trabajo está en movimiento, la página debe mostrarlo inmediatamente.
El CTA principal post-envío también cambió de una manera importante. En lugar de enviar a los usuarios al índice de historial genérico, la acción principal ahora se vincula directamente a la página de detalle exacta del trabajo. Suena como un cambio pequeño, pero elimina un salto innecesario y hace que el flujo se sienta mucho más intencional.
También eliminamos elementos que eran técnicamente funcionales pero no significativamente útiles:
- texto de estado duplicado en el área de carga
- un botón extra "Cargar Otro Archivo" en la tarjeta de éxito
Los usuarios todavía pueden cargar otro archivo desde la superficie de carga principal. La diferencia es que la interfaz ya no compite consigo misma.
Por qué esto importa en la práctica
La verificación masiva se utiliza a menudo en flujos de trabajo repetitivos y operacionales. Los usuarios pueden cargar varios archivos por día, monitorear varios trabajos en una sesión de trabajo y regresar más tarde para descargar resultados filtrados. En ese tipo de entorno, incluso pequeñas piezas de duplicación de UI se suman.
Limpiar el estado post-carga ayuda de tres maneras:
- Reduce la cantidad de análisis de pantalla requerida justo después del envío.
- Hace que el siguiente paso sea obvio.
- Mantiene la interfaz alineada con el modelo mental del usuario: "Mi archivo está adentro. Ahora quiero seguir este trabajo."
Este es el tipo de mejora que rara vez hace una captura de pantalla llamativa por sí sola, pero hace que el producto se sienta más tranquilo y coherente cada día.
Ejemplo: el nuevo camino post-envío
Aquí está el viaje del usuario previsto ahora:
- Cargue un CSV en el flujo de verificación masiva.
- Vea un estado de éxito inmediato con nombre de archivo, conteos de filas y ETA.
- Vea el progreso en vivo sin necesidad de revelarlo manualmente.
- Haga clic en un botón principal para abrir la página de detalle de historial exacta para ese trabajo.
- Regrese más tarde a través de correo electrónico o historial para revisar resultados y exportaciones.
Ese es un camino más simple que:
- Cargar archivo.
- Analizar áreas de estado duplicadas.
- Hacer clic en historial genérico.
- Encontrar la fila correcta.
- Reabrir el trabajo objetivo.
La reducción en el esfuerzo es pequeña en una única sesión y significativa en el uso repetido.
2. El historial de verificación ahora se comporta como una verdadera superficie de monitoreo
La segunda mejora importante fue en la página de historial de verificación asincrónica.
Esta página solía ser funcional, pero básica. Podía mostrar que un trabajo existía y que estaba en progreso, pero aún no se sentía como una superficie diseñada para monitoreo activo.
Eso es un desajuste para un trabajo de verificación de larga duración.
Cuando un cliente abre una página de detalle del historial mientras un archivo aún se está procesando, no solo buscan un número de porcentaje. Están intentando entender:
- a qué archivo se refiere este trabajo
- cuál es el tamaño de la carga de trabajo
- cuánto trabajo ya se ha completado
- cómo se ve la mezcla de resultados iniciales
- cuánto tiempo tardará probablemente el trabajo
Rediseñamos la página alrededor de esa realidad.
Los metadatos estables ahora aparecen primero
La página de historial actualizada ahora comienza con una tarjeta de resumen estable. Esa tarjeta reúne los metadatos de trabajo más importantes:
- nombre de archivo original
- filas totales
- recuento único de correo electrónico
- tiempo de procesamiento estimado
- hora de inicio
Esta información no depende del bucle de sondeo en tiempo real. Eso importa porque el contexto estable debe aparecer lo antes posible, incluso si la carga útil de estado dinámico aún se está estabilizando o actualizando.
Cuando los usuarios llegan a la página, pueden orientarse inmediatamente en lugar de esperar a que una respuesta de estado en vivo haga todo el trabajo.
El área de progreso en vivo es mucho más completa
Debajo del resumen, la experiencia de estado en ejecución es ahora materialmente mejor.
En lugar de una barra de progreso desnuda con contexto limitado, la página ahora expone:
- volumen procesado
- volumen restante
- distribución de resultados entre estados
- semántica de idioma y ETA que coincide con el flujo de verificación masiva principal
Igualmente importante, elimina métricas internas que deben mantenerse internas. Dejamos de exponer intencionalmente los recuentos de tareas de trabajador y fragmentos en la superficie orientada al usuario. Esos valores pueden ser útiles operacionalmente, pero no son lo que los clientes están intentando medir cuando preguntan: "¿Qué tan avanzado está mi trabajo?"
La pregunta correcta casi siempre es centrada en correo electrónico, no centrada en colas.
Las herramientas de estado completado permanecen intactas
Una de las restricciones de diseño para este trabajo fue que no queríamos perder la profundidad analítica de la página de trabajo completado.
Así que mantuvimos el gráfico de desglose de resultados existente y las herramientas de exportación. La actualización no fue sobre reemplazar la experiencia de estado completado. Fue sobre fortalecer la parte superior de la página y hacer que la experiencia de estado en ejecución sea digna del flujo de trabajo.
Eso significa que la página ahora hace ambos trabajos mejor:
- durante el procesamiento, funciona como una superficie de monitoreo
- después de la finalización, aún funciona como una superficie de análisis y exportación
Ejemplo: lo que los usuarios ahora pueden entender de un vistazo
Una página de trabajo en ejecución ahora responde rápidamente a todas estas preguntas:
- "Este es el archivo de 19.293 filas que cargué anteriormente."
- "Tiene 19.010 correos electrónicos únicos."
- "El sistema estima alrededor de 33 minutos."
- "Ya se han verificado 499 correos electrónicos."
- "La mayoría del conjunto completado hasta ahora es válido, con una cuota más pequeña inválida y desconocida."
Ese es un modelo mental mucho más útil que un solo número de porcentaje con semántica poco clara.
3. La semántica del progreso es ahora más honesta
Una de las lecciones más importantes en productos asincronos es que "progreso" no es un concepto único.
En un sistema distribuido, hay varias cosas que pueden avanzar de forma independiente:
- las tareas del worker pueden finalizar
- los chunks pueden fusionarse
- los resultados a nivel de correo electrónico pueden acumularse
- los archivos finales pueden volverse descargables
Si un cliente solo recibe un campo progress genérico, tiene que adivinar cuál de esos significados lleva el número. Así es como terminas con estados de UI que son técnicamente consistentes pero experiencialmente confusos.
Queríamos solucionar eso a nivel de contrato.
El cambio central
La interfaz actualizada hace posible distinguir entre:
email_progresschunk_progressprogress_source
Esa distinción proporciona a los clientes una base mucho más sólida para renderizar el progreso de una manera que coincida con la intención del usuario.
Por ejemplo:
- la barra de progreso grande orientada al usuario ahora puede priorizar
email_progress - las vistas operativas o de diagnóstico aún pueden usar
chunk_progress - si se requiere un fallback,
progress_sourcepuede hacerlo explícito
Este es un modelo mucho más saludable que pretender que todos los porcentajes de progreso significan lo mismo.
Carga útil de ejemplo
Aquí está el tipo de forma que esto permite:
{
"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"
}
Sin saber nada sobre el sistema de cola subyacente, un cliente puede tomar buenas decisiones a partir de esta respuesta.
Eso importa porque las APIs no solo devuelven datos. Definen significado.
Por qué esto es mejor para los clientes
Los clientes no se preocupan por si un worker completó 7 de 96 tareas internas si solo 499 de 19,010 correos electrónicos han sido realmente procesados. Exponer la abstracción de progreso incorrecta crea confusión, no seguridad.
Al mover la UI principal hacia email_progress, el producto ahora refleja la unidad de trabajo que los usuarios realmente se preocupan.
Por qué esto es mejor para los equipos de frontend
La UI ya no tiene que inferir demasiado de un único campo de porcentaje ambiguo.
Esto reduce una clase completa de errores de producto:
- barras de progreso que parecen demasiado adelantadas
- bloques de resumen que se quedan atrás del porcentaje principal
- copias de estado incómodas que intentan explicar detalles de implementación del backend a los usuarios finales
También da a los equipos de frontend una forma más limpia de separar metadatos de trabajos estables de datos de ejecución cambiantes, lo que conduce directamente a la siguiente parte de la versión.
4. El contrato de estado del backend ahora está mejor estructurado para trabajo distribuido
Los cambios en el frontend no se mantendrían bien sin mejoras en el contrato del backend.
Tomamos dos decisiones estructurales importantes aquí.
Primero, separamos metadatos estables del estado en vivo
Algunos campos apenas cambian, si es que cambian, después de que se crea un trabajo:
- nombre de archivo
- hora de creación
- filas totales
- recuento único de correos electrónicos
- tiempo de procesamiento estimado
Otros campos son inherentemente dinámicos:
- estado actual
- recuento de correos electrónicos procesados
- mezcla de resultados en vivo
- porcentajes de progreso
Intentar forzar ambas clases de datos a través de la misma ruta de sondeo es una fuente común de torpeza en la UI. El frontend termina esperando datos que deberían haber estado disponibles inmediatamente, mientras que también solicita datos estables más a menudo de lo necesario.
El nuevo modelo es más limpio:
- los metadatos de trabajo estables se tratan como metadatos
- el estado de trabajo en vivo se trata como estado
Eso suena obvio cuando se escribe claramente, pero tiene efectos significativos en la calidad de la implementación.
La página de detalle del historial ahora puede representar información de resumen estable rápidamente, sondear solo lo que necesita cambiar, y mantener la UI tranquila mientras se ejecuta el trabajo.
Segundo, ampliamos el propio payload de estado
La interfaz de estado en tiempo real ahora está mejor adaptada al procesamiento asincrónico distribuido porque lleva una imagen más rica de lo que ha sucedido hasta ahora.
Esto incluye contadores como:
- procesado
- válido
- inválido
- desconocido
- riesgoso
- catch-all
- rol
- desechable
- créditos utilizados
Esos valores hacen que la interfaz sea más útil no solo para superficies de progreso orientadas al usuario, sino también para automatización y flujos de trabajo posteriores. Un cliente que entiende la mezcla de resultados actual puede tomar mejores decisiones sobre alertas, notificaciones, exportaciones y postprocesamiento.
Ejemplo: por qué esto importa más allá de la UI
Imagina una aplicación orientada al cliente construida sobre BillionVerify que quiera:
- mostrar distribución de calidad en vivo mientras se ejecuta una lista
- notificar a un usuario si un trabajo está produciendo una tasa de inválidos inusualmente alta
- ofrecer exportaciones filtradas tan pronto como existan conjuntos de resultados útiles
- potenciar un panel de control de soporte u operaciones sin requerir que la ingeniería inspeccione el estado del trabajador sin procesar
Todos esos casos de uso se vuelven más fáciles cuando el contrato de estado del backend es explícito y lo suficientemente rico.
Por eso el trabajo de interfaz del backend importa incluso cuando el primer cambio visible es "la barra de progreso se ve mejor". Una barra de progreso mejor es a menudo el síntoma de un contrato mejor.
5. MCP ahora se ha movido completamente a su era remota de OAuth
La última pieza principal de esta actualización está orientada a desarrolladores, pero es una de las correcciones de producto más importantes a largo plazo en la versión.
BillionVerify MCP ahora se presenta y documenta en la forma en que debería estar para clientes remotos modernos:
- un endpoint remoto alojado
- autorización basada en OAuth
- descubrimiento de recursos protegidos
- acceso estándar con token Bearer
El endpoint es:
https://mcp.billionverify.com/mcp
Esto importa porque los patrones de configuración más antiguos pueden perdurar en materiales públicos mucho después de que una plataforma ya se haya movido internamente. En nuestro caso, algunos documentos y superficies de marketing todavía implicaban que MCP podría conectarse a través de claves API incrustadas en URL y envoltorios curl --stdio.
Esa ya no es la forma correcta para BillionVerify MCP.
El modelo mental antiguo
El patrón anterior se veía más o menos así:
curl --stdio "https://mcp.billionverify.com/mcp?api_key=YOUR_API_KEY"
Ese modelo colapsa varios aspectos en un paso de configuración incómodo:
- transporte
- autenticación
- manejo de secretos
- comportamiento del envoltorio local
También envía la señal incorrecta sobre cómo un servidor MCP remoto alojado debe ser consumido por clientes modernos.
El nuevo modelo mental
El modelo actual es más limpio.
Para Claude Code, la configuración recomendada es:
claude mcp add --transport http billionverify https://mcp.billionverify.com/mcp
Luego dentro de Claude Code:
/mcp
Desde allí, el cliente completa el flujo de OAuth en el navegador.
Para ChatGPT y otros clientes MCP remotos compatibles, el punto de partida correcto es simplemente el endpoint mismo:
https://mcp.billionverify.com/mcp
El cliente descubre los metadatos de recursos protegidos, sigue el flujo de autorización y luego utiliza tokens de acceso Bearer para llamadas autenticadas.
La distinción más importante: la autenticación de MCP no es autenticación REST
Una razón por la que los documentos más antiguos necesitaban limpieza es que las claves API aún importan en BillionVerify. Pero ya no pertenecen a la historia de arranque de MCP.
La división limpia es:
- REST API utiliza claves API
- MCP remoto utiliza OAuth
Esa distinción ahora es mucho más clara en toda la superficie del producto.
Si un desarrollador está utilizando:
- ChatGPT
- Claude Code
- otro cliente MCP remoto compatible con OAuth
debería utilizar la ruta MCP remota.
Si están construyendo:
- automatización backend a backend
- scripts impulsados por claves API
- clientes que solo admiten stdio local más claves API
deberían utilizar la referencia de API y el flujo REST en su lugar.
Esto no es una distinción cosmética. Es un límite de producto, y los documentos deberían hacerlo obvio.
6. Los documentos públicos y el marketing ahora coinciden con el producto
Una actualización arquitectónica solo resuelve parte del problema si los materiales públicos todavía cuentan una historia diferente.
Por eso tratamos la limpieza de documentación y marketing de MCP como parte de la misma versión.
Actualizamos:
- la página pública de MCP
- la guía de MCP
- la guía de Claude Code
- puntos de entrada de guías de IA
- variantes de documentación multilingües
- copia de preguntas frecuentes de marketing localizada
El objetivo era simple: debería haber una respuesta clara a la pregunta, "¿Cómo conecto BillionVerify MCP?"
Ahora la hay.
Por qué esto importa para los desarrolladores
Cuando la documentación pública se queda atrás de la realidad de implementación, los desarrolladores pagan el precio de tres formas:
- Intentos de configuración fallidos
- Pérdida de confianza en la plataforma
- Carga de soporte adicional para aclarar lo que debería haber sido obvio
Al alinear la superficie pública con el modelo OAuth remoto actual, reducimos fricción innecesaria antes de que se convierta en un problema de soporte.
Por qué esto importa para el posicionamiento de la plataforma
El ecosistema MCP se está moviendo rápidamente. A medida que más equipos evalúan herramientas a través de ChatGPT, Claude Code y otros clientes de IA, la calidad de la primera experiencia de integración importa más.
Un producto que se ve moderno en la capa de protocolo pero anticuado en su orientación de configuración pública crea dudas justo donde debería estar construyendo confianza.
Por eso también fortalecimos las superficies de inicio de sesión y consentimiento con Términos más claros, Privacidad y visibilidad de contacto de soporte. Revisores, desarrolladores y evaluadores empresariales se benefician cuando las señales de confianza son explícitas.
7. Una vista práctica antes y después de esta versión
Una forma útil de entender la versión es comparar la experiencia del usuario y del desarrollador antes y después.
Antes
- Un archivo de verificación masiva podía enviarse correctamente, pero el estado posterior al envío aún tenía UI duplicada y pasos siguientes menos obvios.
- La página de detalle del historial mostraba actividad, pero aún no se sentía como una superficie de monitoreo completa.
- Un valor de porcentaje completado podía existir sin comunicar claramente a los usuarios si representaba correos procesados o finalización de tareas internas.
- Los materiales públicos de MCP aún reflejaban parcialmente una historia de configuración heredada
?api_key=.
Después
- La experiencia posterior al envío es más limpia, más compacta y más directa.
- El progreso en vivo aparece por defecto en el flujo masivo.
- El CTA principal después del envío lleva a los usuarios directamente a la página de detalle del trabajo exacto.
- Las páginas de detalle del historial muestran metadatos de resumen estables más visibilidad de resultados en vivo más rica.
- El progreso visible para el usuario ahora se centra en la semántica del progreso a nivel de correo electrónico.
- Los conteos de tareas internas ya no se exponen como métricas orientadas al cliente.
- La interfaz de estado del backend está mejor estructurada para clientes en tiempo real y trabajos distribuidos.
- Los materiales públicos de MCP ahora reflejan consistentemente la arquitectura OAuth remota.
Eso no es una sola característica. Es un paso de calidad significativo en todo un flujo de trabajo.
8. Qué significa esto para diferentes audiencias
Para equipos de operaciones y crecimiento
Obtienes un flujo de verificación masiva más fluido con menos fricción en la interfaz, mejor visibilidad mientras se ejecutan los trabajos y acceso más claro al trabajo exacto que acabas de lanzar.
Para equipos de producto y frontend
Ahora tienes semántica de progreso más fuerte y separación más limpia entre metadatos y estado activo, lo que facilita la construcción de pantallas pesadas en progreso y más fácil de explicar.
Para equipos de backend y plataforma
Tienes un contrato de estado más fuerte para verificación distribuida y una historia más clara sobre lo que realmente significan los diferentes valores de progreso.
Para desarrolladores que integran MCP
Ahora tienes una respuesta mucho más clara a la pregunta de configuración: usa MCP remoto más OAuth para clientes MCP, y usa claves API para la API REST donde ese modelo sea apropiado.
9. Por dónde empezar
Si deseas explorar la experiencia actualizada o las rutas de integración, comienza aquí:
- Obtén más información sobre el producto: Verificación de correo electrónico
- Ejecuta flujos de trabajo más grandes: Verificación masiva de correo electrónico
- Comprende los fundamentos: ¿Qué es la verificación de correo electrónico?
- Conecta MCP desde un cliente compatible: Descripción general de MCP
- Profundiza en la configuración: Guía de MCP
- Configura Claude Code específicamente: Guía de Claude Code
- Utiliza integración basada en clave API en su lugar: Referencia de API
Cierre
Esta versión no se trataba de una gran superficie llamativa. Se trataba de ajustar el producto donde la ambigüedad se había colado.
Hicimos más limpio el viaje de verificación masiva. Hicimos más útil el monitoreo asincrónico. Hicimos más verídicos los reportes de progreso. E hicimos que la historia de MCP coincidiera con la plataforma que estamos construyendo.
Esas mejoras se refuerzan mutuamente.
Un producto se vuelve más fácil de confiar cuando la UI dice menos pero significa más. Se vuelve más fácil de integrar cuando la documentación describe la arquitectura real. Y se vuelve más fácil de evolucionar cuando las interfaces debajo de la experiencia llevan semántica más clara.
Esa es la dirección en la que continuamos impulsando BillionVerify.
Si ya estás usando BillionVerify, estos cambios deberían hacer que tu flujo de trabajo diario se sienta más directo y más predecible.
Si estás evaluando la plataforma ahora, esta actualización es una buena instantánea de cómo pensamos en la calidad del producto: claridad orientada al usuario en la parte superior, contratos explícitos debajo, y documentación que coincida con la realidad.