Puntos destacados
Ahora puedes componer, enviar y reproducir requests con tu propia API key directamente en el dashboard. El nuevo playground cubre los tres productos y mantiene cookies, ajustes preestablecidos e historial entre ejecuciones. Se incluyeron dos correcciones de fiabilidad junto con esto: unblocker: true se estuvo degradando silenciosamente durante varias semanas (vuelve a funcionar, end-to-end) y Browser ahora captura la cookie cf_clearance del passive challenge de Cloudflare de forma fiable.
Novedades
El Dashboard Playground
/dashboard/#playground es ahora un verdadero entorno de trabajo. Tres pestañas de producto (Single, Proxy Finder, Browser), barra de URL, headers, body y todos los flags por producto expuestos y adaptados al schema real de cada producto. Envía el request y observa cómo se renderiza la response con modos de vista JSON, HTML y texto. Busca en los paneles de response con Ctrl/Cmd+K. Expande la response a pantalla completa cuando necesites leer un bloque extenso de HTML.
Algunas características surgidas de crearlo tal como nos gustaría usarlo a nosotros mismos:
- Las cookies que recibes se guardan en un jar por host. El siguiente request al mismo host las adjunta automáticamente, y puedes inspeccionar, editar o eliminar cualquier cookie antes de enviar.
- Un panel lateral de proxies funcionales recopila cada ID de proxy devuelto por una ejecución exitosa de Proxy Finder, para que puedas hacer clic en "usar" y reutilizar ese proxy en un request de Single o Browser sin volver a escribirlo.
- Guarda requests como ajustes preestablecidos. Reproduce cualquiera de tus últimas 20 ejecuciones desde un diálogo de historial.
- Un generador de cURL muestra el comando exacto (con
x-api-key) que ejecutarías desde una terminal para enviar el mismo request.
El playground firma un token interno de corta duración, por lo que tu key en texto plano nunca sale del dashboard. La cuota, las métricas y last_used_at se descuentan de la key que seleccionaste, exactamente igual que si hubieras enviado el request desde tu propio código.
unblocker: true funciona de nuevo, end-to-end
Detectamos un problema de compilación que estuvo degradando silenciosamente los requests de Single y Proxy Finder con unblocker: true durante las últimas semanas. La versión se desplegó sin el perfil de navegador debidamente integrado, por lo que los requests que debían llevar una firma de navegador recibían una firma de request genérica. Los sitios que debían dejarnos pasar nos estaban bloqueando.
La corrección está desplegada. Verificamos end-to-end en once destinos reales, incluidos tres detrás de páginas de verificación que antes requerían Browser. Single los supera por sí solo. El flujo encadenado Proxy Finder + Browser + Single (encontrar un proxy, obtener una cookie cf_clearance de Browser, enviar el request de la página con Single más la cookie más el mismo proxy) devuelve el HTML completo en un solo round trip.
Este error fue nuestro. unblocker: true funcionó el día de su lanzamiento y se rompió de forma silenciosa durante una recompilación rutinaria. Si ejecutaste un request con unblocker: true contra un sitio protegido en las últimas semanas y obtuviste un 403 cuando esperabas un 200, esa fue la razón. Pruébalo de nuevo.
Browser gestiona el challenge pasivo de JavaScript de Cloudflare
Cloudflare tiene dos modos de challenge. El modo activo (HTTP 403 más interstitial) ya lo gestionábamos. El pasivo es más engañoso: la página devuelve 200 de inmediato, pero Cloudflare inyecta un probe de JavaScript asíncrono que realiza el fingerprinting del cliente y solo entonces emite la cookie cf_clearance. Antes de esta corrección, Browser finalizaba la response antes de que el probe pudiera completarse, por lo que la clearance cookie nunca llegaba al jar.
Browser ahora escucha el evento Set-Cookie de forma explícita y espera a cf_clearance si detecta el marcador de challenge pasivo en el body. Sin polling, sin periodos de gracia fijos y sin esperas adicionales para sitios que no son de Cloudflare. Doce dominios del mundo real en la suite de pruebas, tres de ellos en la ruta pasiva, ahora devuelven clearance cookies de forma fiable.
Se cerró una brecha de SSRF en el edge de la API
Una API key válida de pk_live_... no es una licencia para acceder a nuestra red privada. La API ahora rechaza cualquier target cuyo hostname literal o resolución DNS caiga en un bloque reservado de RFC 5735, 6598 o IPv6. La misma comprobación se ejecuta en cada producto del backend como segunda línea de defensa.
No verás nada diferente en la superficie. Cerramos una clase de probe de red interna antes de que pueda completar un handshake TCP.
El blog recibe vistas previas sociales únicas y se corrige la paginación
Cada publicación del blog ahora genera su propia imagen Open Graph con el título y el extracto renderizados en una tarjeta de marca. Pega un enlace de foura.ai/blog/... en Discord, LinkedIn, Slack o Twitter y verás la vista previa específica de la publicación en lugar de una alternativa genérica.
La paginación en el índice del blog fallaba silenciosamente. El botón "Older" te devolvía a la página 1. La reconstruimos con URL basadas en rutas (/blog/page/N/), añadimos navegación numerada con una ventana inteligente e incorporamos etiquetas de enlace rel=prev/next adecuadas para series paginadas. Las URL antiguas de ?page=N redirigen con 301 al nuevo formato, por lo que no se pierde nada de lo rastreado previamente.
Bajo el capó
Nuestro servidor MCP está disponible en mcp.foura.ai para cualquier herramienta de LLM compatible con Model Context Protocol. La autenticación utiliza el mismo Bearer token de pk_live_... que usas con la REST API. Expone los tres productos como herramientas (Single, Proxy Finder, Browser) y un conjunto de prompts. Si estás integrando FourA en Claude Code o en cualquier agente compatible con MCP, puedes dejar de ejecutar un puente local.
Si no has usado el dashboard porque el playground anterior era solo un boceto, ábrelo esta semana. Es la interfaz que ahora usamos nosotros mismos cuando algo parece fallar con un target de la API.