Destaques
Agora você pode criar, enviar e reproduzir requests diretamente no dashboard usando sua própria chave de API. O novo playground cobre todos os três produtos e preserva cookies, predefinições e histórico entre execuções. Duas correções de confiabilidade foram lançadas junto com ele: o unblocker: true estava se degradando silenciosamente há várias semanas (ele voltou a funcionar, de ponta a ponta), e o Browser agora captura o cookie de desafio passivo cf_clearance da Cloudflare de forma confiável.
Novidades
O Playground do Dashboard
O /dashboard/#playground agora é uma bancada de trabalho de verdade. Três abas de produtos (Single, Proxy Finder, Browser), barra de URL, headers, body e todas as opções de cada produto expostas e alinhadas ao schema real de cada um. Envie o request e veja a response renderizada nos modos de visualização JSON, HTML e texto. Busque entre os painéis de resposta com Ctrl/Cmd+K. Expanda a response para a tela inteira quando precisar ler grandes blocos de HTML.
Alguns recursos resultantes de construir a ferramenta como nós mesmos gostaríamos de usar:
- Os cookies recebidos são salvos em um jar por host. O próximo request para o mesmo host anexa esses cookies automaticamente, e você pode inspecionar, editar ou excluir qualquer cookie antes de enviar.
- Um painel de proxies funcionais reúne cada proxy id retornado por uma execução bem-sucedida do Proxy Finder, permitindo que você clique em "use" e reutilize esse proxy em um request do Single ou Browser sem precisar digitar novamente.
- Salve requests como predefinições. Reproduza qualquer uma das suas últimas 20 execuções a partir de um modal de histórico.
- Um gerador de comando curl mostra o comando exato (com
x-api-key) que você executaria no terminal para enviar o mesmo request.
O playground assina um token interno de curta duração, de modo que sua chave em texto puro nunca sai do dashboard. Cota, métricas e last_used_at são contabilizados na chave selecionada, da mesma forma como se você tivesse enviado o request a partir do seu próprio código.
O unblocker: true funciona novamente, de ponta a ponta
Identificamos um problema de build que estava rebaixando silenciosamente requests do Single e do Proxy Finder com unblocker: true nas últimas semanas. A versão foi lançada sem o perfil de browser devidamente conectado, então requests que deveriam ter uma assinatura de browser recebiam uma assinatura genérica de request. Sites que deveriam nos liberar estavam nos bloqueando.
A correção foi implementada. Validamos de ponta a ponta em onze alvos reais, incluindo três protegidos por páginas de verificação que antes exigiam o Browser. O Single passa por eles sozinho. O fluxo encadeado Proxy Finder + Browser + Single (encontrar um proxy, obter um cookie cf_clearance pelo Browser, enviar o request da página com o Single incluindo o cookie e o mesmo proxy) retorna o HTML completo em um único ciclo.
Este erro foi nosso. O unblocker: true funcionou no dia do lançamento e quebrou silenciosamente durante um rebuild de rotina. Se você executou um request com unblocker: true em um site protegido nas últimas semanas e recebeu um 403 em vez de um 200, esse foi o motivo. Tente novamente.
O Browser lida com o desafio passivo de JavaScript da Cloudflare
O Cloudflare tem dois modos de desafio. O modo ativo (HTTP 403 mais interstitial) já era tratado por nós. O passivo é mais sutil: 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 a 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 por cf_clearance se encontrar o marcador de desafio passivo no body. Sem polling, sem período fixo de carência, sem espera adicional para sites que não usam Cloudflare. Doze domínios reais 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 alcançar nossa rede privada. A API agora rejeita qualquer destino cujo literal de hostname ou resolução DNS caia em um bloco reservado RFC 5735, 6598 ou IPv6. A mesma verificação é executada em cada produto do backend como uma segunda linha de defesa.
Você não verá nada diferente na superfície. Bloqueamos uma classe de sondagem 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 do post e o resumo renderizados em um card 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 quebrada de forma silenciosa. O botão "Older" redirecionava você de volta para a página 1. Nós a reconstruímos com URLs baseadas em caminho (/blog/page/N/), adicionamos navegação numerada com janela inteligente e incluímos tags de link rel=prev/next adequadas para séries paginadas. URLs antigas no formato ?page=N retornam 301 para a nova estrutura, garantindo que nada indexado anteriormente seja perdido.
Sob o Capô
Nosso servidor MCP está disponível em mcp.foura.ai para qualquer ferramenta de LLM compatível com o Model Context Protocol. A autenticação utiliza o mesmo Bearer token pk_live_... que você usa na API REST. Ele expõe os três produtos como ferramentas (Single, Proxy Finder, Browser) e um conjunto de prompts. Se você está integrando o FourA ao Claude Code ou a qualquer agente compatível com MCP, pode parar de rodar uma bridge local.
Se você estava evitando o dashboard porque o playground anterior era apenas uma versão básica, acesse-o esta semana. É a interface que nós mesmos usamos agora quando algo parece errado em relação a um endpoint de API.