O Playground está disponível no seu Dashboard. Três endpoints, um cookie jar, todos os headers analisados. Escolha Single, Proxy ou Browser, preencha o request, clique em Send. O response aparece na mesma tela com status, headers, body e cookies analisados. Quando estiver satisfeito, copie o curl funcional para o seu código.
Esta não é uma página separada ou um sandbox em um URL diferente. Ele roda na API real com a sua chave real. O que você vê no Playground é o que o seu código de produção receberá de volta.
Como Funciona
Você faz login no Dashboard, escolhe um dos três endpoints, e o formulário se reconstrói para mostrar apenas os campos que esse endpoint realmente aceita.
- O Single recebe
url,method,headers,unblocker,proxy,tryJsonData,followRedirectse o grupo de timeout. - O Proxy recebe o mesmo conjunto envelopado sob um bloco
request, além dos filtros de seleção de proxy (país, cidade, ASN, anonimato, atualização). - O Browser recebe
url,cookies,headerse as condições de espera.
Quando você clica em Send, o Dashboard autentica a chamada contra a sua conta e faz um POST para /api/{endpoint} em api.foura.ai. Sua chave de API real nunca trafega pela página. O Playground é o único lugar no Dashboard onde você pode disparar um request tarifável sem expor a chave no navegador.
Aqui está o comando curl de reprodução que o Playground exporta para um request Single básico:
curl -X POST 'https://api.foura.ai/api/single' \
-H 'Content-Type: application/json' \
-H 'x-api-key: YOUR_API_KEY' \
--data-raw '{
"url": "https://example.com/products",
"method": "GET",
"unblocker": true,
"tryJsonData": true
}'
Cole isso em um terminal ou script de build e ele se comportará exatamente como o botão Send. Nós não envelopamos o payload em um invólucro personalizado nem renomeamos nenhum dos campos. O Playground envia o que a API aceita, ponto final.
O Que Você Recebe de Volta
O painel de response mostra o status do upstream, o tempo total e (para chamadas de Proxy) o proxy id que processou o request. Body, Headers e Cookies ganham, cada um, sua própria aba.
Body. O JSON detectado automaticamente é renderizado em um visualizador colapsável. Os payloads em HTML alternam para um painel de visualização para que você possa conferir o que o site de destino retornou. O texto muda para uma visualização monoespaçada simples. Há uma caixa de busca em Body e Raw com navegação anterior/próximo.
Headers. Visualização analisada com uma linha por name: value, ou Raw para a cadeia completa de response multi-hop. Cada redirecionamento deixa seu próprio conjunto de headers para trás, então seguir um 302 até seu destino final exige apenas um clique.
Cookies. O jar analisa cada linha Set-Cookie do response, rastreia se cada cookie é restrito ao host (host-only) ou de domínio amplo (RFC 6265 §5.3) e oferece duas visualizações: cartões colapsáveis por host ou a lista bruta. Ative o jar e o próximo request puxará os cookies correspondentes automaticamente. Para Single e Proxy, isso significa um header Cookie no request de saída. Para Browser, significa um array de cookies anexado ao objeto do request.
Os Presets salvam toda a configuração do request sob um nome e descrição, para que você possa voltar rapidamente para "testar login em staging" sem precisar reconstruí-lo. O History mantém suas últimas vinte execuções com status, tipo de conteúdo, tempo total e o proxy utilizado.
Impacto
O que o Playground realmente muda é o loop de iteração.
Antes, você escrevia um script pequeno (Node, Python ou shell), configurava sua chave, chamava a API, imprimia o body, ajustava um header, rodava de novo. Talvez dez minutos entre "o que será que esse site retorna" e ter uma resposta.
No Playground, esse loop fica mais próximo de quinze segundos. Clique no endpoint, cole a URL, clique em Send, olhe os cookies, mude unblocker de desativado para ativado, clique em Send novamente. No tempo que você levaria para abrir seu editor, você já sabe qual versão do request funciona no seu alvo.
Não lançamos o Playground para substituir seu código real. Nós o lançamos para que o caminho entre "isso é sequer possível neste site" e "sim, aqui está o curl que funciona" deixe de envolver um projeto paralelo.
Para Power Users
Algumas coisas que não são óbvias à primeira vista:
Os Presets carregam o payload completo. Isso inclui o grupo de timeout, regras de validação, limite de redirecionamento e quaisquer headers personalizados. Quando você salva um preset, você está tirando um snapshot de um request testado, não apenas da URL. Útil quando você mantém um conjunto de smoke tests estáveis entre endpoints.
O cookie jar é por sessão. Ele vive no seu navegador. Nós não persistimos os cookies capturados no lado do servidor. Recarregue a aba se precisar de um estado limpo.
A aba Raw e o formulário permanecem sincronizados. Os campos do formulário renderizam o mesmo JSON que a aba Raw mostra. Cole um payload no Raw e o formulário se reidrata. Assim, um colega de trabalho pode enviar um request funcional no chat, você o cola no Raw e o formulário se preenche sozinho.
Os cookies do Browser têm formato de objeto, não de header. Se você estiver enviando cookies para o endpoint Browser manualmente, cada entrada recebe {name, value, domain?, path?, httpOnly?, secure?, sameSite?}. O Playground os constrói corretamente quando o jar está ativado. Se você mesmo os estiver criando, a correspondência do schema importa.
Os resultados aparecem no seu feed de atividade. Quando o Playground dispara um request, ele conta da mesma forma que qualquer outra chamada contra a sua chave. Você o verá no seu log de atividade com o rótulo de resultado correto (success, client_error, application_error, rate_limit, service_error). Útil para reproduzir uma chamada de produção instável: execute-a novamente no Playground, encontre-a no log de atividade e compartilhe o link com a equipe.
O Que Vem a Seguir
O Playground é o primeiro passo em um esforço maior para fazer com que o Dashboard faça mais do que apenas mostrar o que você já fez. Os padrões que vemos no log de requests moldam o que será lançado a seguir.
Se você estiver usando hoje e algo parecer estranho, um campo que não corresponde à documentação, um cookie que não sobreviveu a um redirecionamento, um response que renderiza incorretamente, esse é o feedback que lemos primeiro. O Dashboard vê os requests. Nós vemos as tendências.