Destaques
Agora você pode compor, enviar e repetir requests com sua própria chave de API direto no dashboard. O novo playground cobre todos os três produtos e mantém cookies, presets e histórico entre as execuções. Duas correções de confiabilidade foram lançadas junto com ele: unblocker: true estava degradando silenciosamente por várias semanas (voltou a funcionar, de ponta a ponta), e o Browser agora captura o cookie de desafio passivo cf_clearance do Cloudflare de forma confiável.
Novidades
O Playground do Dashboard
/dashboard/#playground é uma bancada de trabalho real agora. Três abas de produtos (Single, Proxy Finder, Browser), uma barra de URL, headers, body, todas as flags por produto expostas e mapeadas para o schema real de cada produto. Envie o request, veja o response renderizar com modos de visualização em JSON, HTML e texto. Busque entre os painéis de response com Ctrl/Cmd+K. Expanda o response para o viewport completo quando precisar ler uma parede de HTML.
Algumas coisas que surgiram ao construí-lo da maneira que nós mesmos gostaríamos de usar:
- Os cookies que você recebe são salvos em um jar por host. O próximo request para o mesmo host os anexa automaticamente, e você pode inspecionar, editar ou excluir qualquer cookie antes de enviar.
- Uma barra lateral de proxies ativos coleta cada proxy id retornado de uma execução bem-sucedida do Proxy Finder, para que você possa clicar em "use" e reutilizar esse proxy em um request do Single ou Browser sem precisar digitar novamente.
- Salve requests como presets. Reexecute qualquer uma das suas últimas 20 execuções a partir de um diálogo de histórico.
- Um reprodutor de curl mostra o comando exato (com
x-api-key) que você executaria em um terminal para enviar o mesmo request.
O playground assina um token interno de curta duração, para que sua chave em texto simples nunca saia do dashboard. Cota, métricas e last_used_at contam contra a chave que você escolheu, da mesma forma que contariam se você tivesse enviado o request a partir do seu próprio código.
unblocker: true funciona novamente, de ponta a ponta
Detectamos um problema de build que estava degradando silenciosamente os requests do Single e do Proxy Finder com unblocker: true nas últimas semanas. O build foi implantado sem o bypass realmente interligado, de modo que os requests que deveriam ter superado as barreiras de anti-bot no nível de handshake estavam recebendo uma assinatura de request genérica. Sites que deveriam ter nos deixado passar estavam nos bloqueando.
A correção foi implantada. Verificamos de ponta a ponta em onze alvos do mundo real, incluindo três em interstitials do Cloudflare que antes exigiam o Browser para passar. O Single passa por eles sozinho. O fluxo encadeado Proxy Finder + Browser + Single (encontrar um proxy, obter um cookie cf_clearance do Browser, enviar o request da página com o Single mais o cookie mais o mesmo proxy) retorna o HTML completo em um único round trip.
Este erro foi nosso. O unblocker: true funcionou no dia em que foi lançado e quebrou silenciosamente durante um rebuild de rotina. Se você executou um request com unblocker: true contra um site protegido nas últimas semanas e viu um 403 onde esperava um 200, foi por isso. Tente novamente.
Browser lida com o desafio JavaScript passivo do Cloudflare
O Cloudflare tem dois modos de desafio. O modo ativo (HTTP 403 mais interstitial) nós já tratávamos. O passivo é mais traiçoeiro: a página retorna 200 imediatamente, mas o Cloudflare injeta uma sonda JavaScript assíncrona que faz o fingerprint do cliente e só então emite o cookie cf_clearance. Antes desta correção, o Browser finalizava o response antes que a sonda pudesse ser concluída, de modo que o cookie de clearance nunca chegava ao jar.
O Browser agora escuta o evento Set-Cookie explicitamente e aguarda pelo cf_clearance se vir o marcador de desafio passivo no body. Sem polling, sem período de carência fixo, sem espera extra para sites que não são do Cloudflare. Doze domínios do mundo real na suíte de testes, três deles no caminho passivo, agora retornam cookies de clearance de forma confiável.
Fechada uma brecha de SSRF na borda da API
Uma chave de API pk_live_... válida não é uma licença para acessar nossa rede privada. A API agora rejeita qualquer alvo cujo hostname literal ou resolução de DNS caia em um bloco reservado RFC 5735, 6598 ou IPv6. A mesma verificação é executada em cada produto de backend como uma segunda linha de defesa.
Você não verá nada de diferente na superfície. Fechamos uma classe de sonda de rede interna antes que ela possa concluir um handshake TCP.
Blog ganha previews sociais exclusivos, paginação corrigida
Cada post do blog agora gera sua própria imagem Open Graph com o título e o resumo (excerpt) do post renderizados em um cartão da marca. Cole um link foura.ai/blog/... no Discord, LinkedIn, Slack ou Twitter e você verá o preview específico do post em vez de um fallback genérico.
A paginação no índice do blog estava silenciosamente quebrada. O botão "Older" levava você de volta para a página 1. Nós o reconstruímos com URLs baseadas em caminhos (/blog/page/N/), adicionamos navegação numerada com uma janela inteligente e adicionamos tags de link rel=prev/next adequadas para séries paginadas. URLs antigas ?page=N fazem redirecionamento 301 para o novo formato, de modo que nada rastreado antes disso seja perdido.
Por Baixo dos Panos
Nosso servidor MCP está ativo em mcp.foura.ai para qualquer ferramenta de LLM que fale o Model Context Protocol. A autenticação é o mesmo token Bearer pk_live_... que você usa na API REST. Ele expõe os três produtos como ferramentas (Single, Proxy Finder, Browser) e um punhado de prompts. Se você estiver integrando o FourA ao Claude Code ou a qualquer agente compatível com MCP, pode parar de executar um bridge local.
Se você estava evitando o dashboard porque o playground anterior era apenas um esboço, abra-o esta semana. É a interface que nós mesmos usamos agora quando algo parece errado com um alvo de API.