Le Playground : construisez et testez vos requests dans votre Dashboard

Le Playground est disponible dans votre Dashboard. Trois endpoints, un cookie jar, chaque header analysé. Choisissez Single, Proxy ou Browser, configurez la request, cliquez sur Send. La response s'affiche sur le même écran avec le statut, les headers, le body et les cookies analysés. Une fois satisfait, copiez le cURL fonctionnel dans votre code.

Il ne s'agit pas d'une page distincte ou d'un bac à sable hébergé sur une autre URL. Il fonctionne directement avec l'API réelle et votre clé active. Ce que vous voyez dans le Playground correspond exactement à ce que votre code de production recevra.

Comment ça fonctionne

Vous vous connectez au Dashboard, choisissez l'un des trois endpoints, et le formulaire s'adapte automatiquement pour n'afficher que les champs acceptés par cet endpoint.

• Single reçoit url, method, headers, unblocker, proxy, tryJsonData, followRedirects et le groupe timeout.
• Proxy reçoit le même ensemble encapsulé dans un bloc request, plus les filtres de sélection de proxy (pays, ville, ASN, anonymat, fraîcheur).
• Browser reçoit url, cookies, headers et les conditions d'attente.

Lorsque vous cliquez sur Send, le Dashboard authentifie l'appel sur votre compte et effectue un POST vers /api/{endpoint} sur api.foura.ai. Votre clé API réelle ne transite jamais par la page. Le Playground est le seul endroit du Dashboard où vous pouvez lancer une request facturable sans exposer votre clé dans le navigateur.

Voici le cURL de reproduction généré par le Playground pour une request Single de base :

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
  }'

Collez cela dans un terminal ou un script de build et il se comportera exactement comme le bouton Send. Nous n'encapsulons pas le payload dans une enveloppe personnalisée et ne renommons aucun champ. Le Playground envoie ce que l'API accepte, un point c'est tout.

Ce que vous recevez en retour

Le panneau de response affiche le statut amont, le temps total et (pour les appels Proxy) l'id du proxy qui a traité la request. Le Body, les Headers et les Cookies ont chacun leur propre onglet.

Body. Le JSON détecté automatiquement s'affiche dans une vue repliable. Les payloads HTML basculent vers un volet de prévisualisation pour vous permettre de vérifier visuellement ce que le site cible a renvoyé. Le texte brut s'affiche dans une police à chasse fixe. Un champ de recherche est disponible sur le Body et le Raw avec navigation précédent/suivant.

Headers. Une vue analysée avec une ligne par name: value, ou Raw pour la chaîne complète de responses multi-sauts. Chaque redirection laisse son propre ensemble de headers, de sorte que suivre un 302 vers sa destination finale se fait en un clic.

Cookies. Le jar analyse chaque ligne Set-Cookie de la response, détermine si chaque cookie est limité à l'hôte ou étendu au domaine (RFC 6265 §5.3), et propose deux vues : des cartes repliables par hôte ou la liste brute. Activez le jar et la prochaine request inclura automatiquement les cookies correspondants. Pour Single et Proxy, cela se traduit par un header Cookie sur la request sortante. Pour Browser, cela se traduit par un tableau de cookies associé à l'objet request.

Les presets enregistrent l'intégralité de la configuration de la request sous un nom et une description, vous permettant de revenir rapidement à "test login on staging" sans avoir à tout reconstruire. L'historique conserve vos vingt derniers lancements avec leur statut, leur type de contenu, le temps total et le proxy utilisé.

L'impact

Ce que le Playground change réellement, c'est la boucle d'itération.

Auparavant, vous écriviez un script rapide (Node, Python ou shell), configuriez votre clé, appeliez l'API, affichiez le body, ajustiez un header, puis relanciez le tout. Comptez environ dix minutes entre le moment où vous vous demandiez "qu'est-ce que ce site renvoie" et l'obtention d'une réponse.

Dans le Playground, cette boucle est plus proche des quinze secondes. Cliquez sur l'endpoint, collez l'URL, cliquez sur Send, examinez les cookies, passez unblocker de désactivé à activé, cliquez à nouveau sur Send. Le temps d'ouvrir votre éditeur, vous savez déjà quelle version de la request fonctionne sur votre cible.

Nous n'avons pas lancé le Playground pour remplacer votre code réel. Nous l'avons conçu pour que le chemin entre "est-ce seulement faisable sur ce site" et "oui, voici le cURL qui fonctionne" ne nécessite plus de créer un projet secondaire.

Pour les utilisateurs avancés

Quelques détails qui ne sont pas évidents au premier coup d'œil :

Les presets contiennent l'intégralité du payload. Cela inclut le groupe timeout, les règles de validation, la limite de redirection et tous les headers personnalisés. Lorsque vous enregistrez un preset, vous capturez une request testée, pas seulement l'URL. Pratique pour conserver un ensemble de smoke tests stables sur différents endpoints.

Le cookie jar fonctionne par session. Il réside dans votre navigateur. Nous ne conservons pas les cookies capturés côté serveur. Rechargez complètement l'onglet si vous avez besoin d'un état propre.

L'onglet Raw et le formulaire restent synchronisés. Les champs du formulaire affichent le même JSON que celui de l'onglet Raw. Collez un payload dans Raw et le formulaire se remplit automatiquement. Ainsi, si un collègue vous partage une request fonctionnelle par messagerie, il vous suffit de la coller dans Raw pour que le formulaire se configure de lui-même.

Les cookies de Browser sont structurés sous forme d'objets, pas de headers. Si vous envoyez manuellement des cookies à l'endpoint Browser, chaque entrée requiert {name, value, domain?, path?, httpOnly?, secure?, sameSite?}. Le Playground les construit correctement lorsque le jar est activé. Si vous les concevez vous-même, le respect du schéma est indispensable.

Les résultats apparaissent dans votre flux d'activité. Lorsqu'un Playground lance une request, elle est comptabilisée comme n'importe quel autre appel lié à votre clé. Vous la verrez dans votre journal d'activité avec le bon label de résultat (success, client_error, application_error, rate_limit, service_error). Pratique pour reproduire un appel de production instable : relancez-le dans le Playground, retrouvez-le dans le journal d'activité et partagez le lien avec votre équipe.

Et ensuite ?

Le Playground est la première étape d'une initiative plus large visant à faire du Dashboard un outil qui ne se contente pas d'afficher votre historique. Les schémas que nous observons dans le journal des requests orientent nos prochains développements.

Si vous l'utilisez aujourd'hui et que quelque chose vous semble anormal (un champ non conforme à la documentation, un cookie perdu lors d'une redirection, une response mal affichée), c'est ce type de retour que nous lisons en priorité. Le Dashboard voit les requests. Nous voyons les tendances.