El Playground ya está disponible en su Dashboard. Tres endpoints, un cookie jar, cada header analizado. Elija Single, Proxy o Browser, complete el request y pulse Send. La response aparece en la misma pantalla con el status, los headers, el body y las cookies analizadas. Cuando esté conforme, copie el curl resultante en su código.
Esto no es una página separada ni un sandbox alojado en una URL diferente. Se ejecuta contra la API real con su clave real. Lo que ve en el Playground es lo que recibirá su código de producción.
Cómo funciona
Inicie sesión en el Dashboard, elija uno de los tres endpoints y el formulario se adaptará automáticamente para mostrar solo los campos que ese endpoint realmente acepta.
- Single recibe
url,method,headers,unblocker,proxy,tryJsonData,followRedirectsy el grupo de timeout. - Proxy recibe el mismo conjunto envuelto en un bloque
request, además de los filtros de selección de proxy (país, ciudad, ASN, anonimato, frescura). - Browser recibe
url,cookies,headersy las condiciones de espera.
Al pulsar Send, el Dashboard autentica la llamada contra su cuenta y realiza un POST a /api/{endpoint} en api.foura.ai. Su clave de API real nunca viaja a través de la página. El Playground es el único lugar del Dashboard donde puede realizar un request facturable sin exponer la clave en el navegador.
Este es el comando curl de reproducción que genera el Playground para un 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
}'
Péguelo en una terminal o en un script de compilación y se comportará exactamente igual que el botón Send. No envolvemos el payload en un contenedor personalizado ni renombramos ningún campo. El Playground envía lo que la API acepta, y punto.
Qué verá de vuelta
El panel de response muestra el status de origen, el tiempo total y (para llamadas Proxy) el proxy id que procesó el request. El Body, los Headers y las Cookies tienen cada uno su propia pestaña.
Body. El JSON detectado automáticamente se renderiza en un visor colapsable. Los payloads de HTML cambian a un panel de vista previa para que pueda examinar visualmente lo que devolvió el sitio de destino. El texto se muestra en una vista monoespaciada simple. Hay un cuadro de búsqueda en Body y Raw con navegación anterior/siguiente.
Headers. Vista analizada con una fila por cada name: value, o Raw para la cadena completa de response de múltiples saltos. Cada redirección deja su propio conjunto de headers, por lo que seguir un 302 hasta su destino final requiere un solo clic.
Cookies. El jar analiza cada línea Set-Cookie de la response, rastrea si cada cookie es solo para el host o para todo el dominio (RFC 6265 §5.3) y ofrece dos vistas: tarjetas colapsables por host o la lista sin procesar. Active el jar y el siguiente request importará las cookies coincidentes de forma automática. Para Single y Proxy, esto se traduce en un header Cookie en el request saliente. Para Browser, significa un array de cookies adjunto al objeto del request.
Los Presets guardan toda la configuración del request con un nombre y una descripción, de modo que pueda volver a "probar el inicio de sesión en staging" sin tener que reconstruirlo. El History conserva sus últimas veinte ejecuciones con su status, tipo de contenido, tiempo total y el proxy utilizado.
Impacto
Lo que el Playground realmente cambia es el ciclo de iteración.
Antes, tenía que escribir un pequeño script (Node, Python o shell), configurar su clave, llamar a la API, imprimir el body, ajustar un header y ejecutarlo de nuevo. Quizás pasaban diez minutos desde "me pregunto qué devuelve este sitio" hasta obtener una respuesta.
En el Playground, ese ciclo se reduce a unos quince segundos. Haga clic en el endpoint, pegue la URL, pulse Send, observe las cookies, cambie unblocker de desactivado a activado y vuelva a pulsar Send. Para cuando haya abierto su editor, ya sabrá qué versión del request funciona en su objetivo.
No lanzamos el Playground para reemplazar su código real. Lo lanzamos para que el camino desde "¿es esto posible en este sitio?" hasta "sí, aquí está el curl que funciona" deje de requerir un proyecto paralelo.
Para usuarios avanzados
Algunos detalles que no resultan obvios a primera vista:
Los Presets contienen el payload completo. Esto incluye el grupo de timeout, las reglas de validación, el límite de redirecciones y cualquier header personalizado. Al guardar un preset, está tomando una captura de un request probado, no solo de la URL. Esto resulta útil si mantiene un conjunto de pruebas de humo estables en distintos endpoints.
El cookie jar es por sesión. Reside en su navegador. No persistimos las cookies capturadas en el servidor. Recargue la pestaña por completo si necesita un estado limpio.
La pestaña Raw y el formulario se mantienen sincronizados. Los campos del formulario renderizan el mismo JSON que se muestra en la pestaña Raw. Pegue un payload en Raw y el formulario se actualizará. De este modo, un compañero de trabajo puede compartir un request funcional en el chat, usted lo pega en Raw y el formulario se completará solo.
Las cookies de Browser tienen forma de objeto, no de header. Si envía cookies al endpoint de Browser manualmente, cada entrada requiere {name, value, domain?, path?, httpOnly?, secure?, sameSite?}. El Playground las construye correctamente cuando el jar está activo. Si las diseña usted mismo, la coincidencia del esquema es fundamental.
Los resultados aparecen en su feed de actividad. Cuando el Playground lanza un request, cuenta igual que cualquier otra llamada contra su clave. Lo verá en su registro de actividad con la etiqueta de resultado correspondiente (success, client_error, application_error, rate_limit, service_error). Esto es útil para reproducir una llamada de producción inestable: ejecútela de nuevo en el Playground, búsquela en el registro de actividad y comparta el enlace con su equipo.
Próximos pasos
El Playground es el primer paso de un esfuerzo mayor para lograr que el Dashboard haga más que solo mostrarle lo que ya hizo. Los patrones que observamos en el registro de requests definen lo que lanzaremos a continuación.
Si lo está utilizando hoy y algo no parece correcto (un campo que no coincide con la documentación, una cookie que no sobrevivió a una redirección o una response que se renderiza de forma incorrecta), ese es el feedback que leemos primero. El Dashboard ve los requests. Nosotros vemos las tendencias.