Playground 已在您的 Dashboard 中上线。三个 endpoint，一个 cookie jar，解析每一个 header。选择 Single、Proxy 或 Browser，填写 request，点击 Send。response 将显示在同一屏幕中，包含 status、header、body 和解析后的 cookie。满意后，将运行成功的 curl 复制到您的代码中。
这不是一个独立的页面，也不是位于其他 URL 后面的沙箱。它使用您的真实 key 直接调用运行中的 API。您在 Playground 中看到的就是您的生产环境代码将收到的内容。
How It Works
登录 Dashboard，选择三个 endpoint 之一，表单会自动重构，仅显示该 endpoint 实际接受的字段。
- Single 包含
url、method、headers、unblocker、proxy、tryJsonData、followRedirects以及 timeout 组。 - Proxy 包含包裹在
request块下的相同字段集，外加 proxy 选择过滤器（country、city、ASN、anonymity、freshness）。 - Browser 包含
url、cookies、headers以及 wait 条件。
当您点击 Send 时，Dashboard 会针对您的账户验证该调用，并向 api.foura.ai 上的 /api/{endpoint} 发送 POST 请求。您的真实 API key 绝不会通过页面传输。Playground 是 Dashboard 中唯一无需在浏览器中暴露 key 即可发起计费 request 的地方。
以下是 Playground 为基础 Single request 生成的 curl 重现代码：
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
}'
将其粘贴到终端或构建脚本中，其行为与 Send 按钮完全一致。我们不会将 payload 包裹在自定义信封中，也不会重命名任何字段。Playground 发送的就是 API 接收的内容，仅此而已。
What You See Back
response 面板显示上游 status、总耗时以及（对于 Proxy 调用）处理该 request 的 proxy id。Body、Headers 和 Cookies 各有独立的标签页。
Body。 自动检测到的 JSON 会在可折叠查看器中渲染。HTML payload 会切换到预览面板，以便您直观查看目标网站返回的内容。文本则降级为纯等宽文本视图。Body 和 Raw 标签页中设有搜索框，支持上一个/下一个跳转。
Headers。 解析视图中每行显示一个 name: value，或者在 Raw 视图中显示完整的多次跳转 response 链。每次重定向都会留下自己的 header 集合，因此只需点击一下即可追踪 302 到其最终目的地。
Cookies。 cookie jar 解析来自 response 的每一行 Set-Cookie，追踪每个 cookie 是仅限主机（host-only）还是全域（domain-wide）（RFC 6265 §5.3），并提供两种视图：按主机折叠的卡片或原始列表。开启 cookie jar 后，下一个 request 会自动拉取匹配的 cookie。对于 Single 和 Proxy，这意味着在发送的 request 中添加 Cookie header。对于 Browser，这意味着在 request 对象中附加 cookie 数组。
Preset 可将整个 request 配置保存在特定的名称和描述下，这样您就可以直接返回 "在测试环境中测试登录"，而无需重新构建。History 保留您最近的 20 次运行记录，包括 status、content type、总耗时以及使用的 proxy。
Impact
Playground 真正改变的是迭代循环。
以前，您需要编写一个微型脚本（Node、Python 或 shell），配置好 key，调用 API，打印 body，调整一个 header，然后再次运行。从 "我想知道这个网站会返回什么" 到获得答案，可能需要十分钟。
在 Playground 中，这个循环缩短到了接近 15 秒。点击 endpoint，粘贴 URL，点击 Send，查看 cookie，将 unblocker 从关闭切换为开启，再次点击 Send。在您打开编辑器的时候，您就已经知道哪个版本的 request 可以在目标网站上正常工作了。
我们推出 Playground 并不是为了取代您的真实代码。我们推出它是为了让 "这个网站到底能不能搞定" 到 "可以，这是可用的 curl" 之间的路径，不再需要创建一个临时项目。
For Power Users
一些从表面上不易发现的细节：
Preset 携带完整的 payload。 这包括 timeout 组、验证规则、重定向限制以及任何自定义 header。当您保存 preset 时，您是在对已测试的 request 进行快照，而不仅仅是 URL。当您需要在不同 endpoint 之间保持一组稳定的冒烟测试时，这非常有用。
cookie jar 是基于 session 的。 它存在于您的浏览器中。我们不会在服务器端持久化捕获的 cookie。如果需要干净的状态，请强制刷新标签页。
Raw 标签页和表单保持同步。 表单字段会渲染 Raw 标签页中显示的相同 JSON。将 payload 粘贴到 Raw 中，表单就会自动填充。因此，同事可以在聊天中发给你一个可用的 request，你将其粘贴到 Raw 中，表单就会自动填好。
Browser cookie 是对象格式，而不是 header 格式。 如果您手动向 Browser endpoint 发送 cookie，每个条目都需要符合 {name, value, domain?, path?, httpOnly?, secure?, sameSite?}。当 cookie jar 开启时，Playground 会正确构建它们。如果您是自己构建，模式（schema）匹配至关重要。
Outcome 会显示在您的活动源中。 当 Playground 发起 request 时，它的计费方式与针对您的 key 发起的任何其他调用相同。您将在活动日志中看到它，并带有正确的 outcome 标签（success、client_error、application_error、rate_limit、service_error）。这对于重现不稳定的生产环境调用非常有用：在 Playground 中重新运行它，在活动日志中找到它，然后将链接分享给团队。
What's Next
Playground 是我们推动 Dashboard 发挥更大作用的第一步，而不仅仅是向您展示已经完成的操作。我们在 request 日志中看到的模式将决定我们下一步推出的功能。
如果您现在正在使用它并觉得有什么地方不对劲，比如字段与文档不匹配、cookie 在重定向后丢失、response 渲染错误，这些都是我们最先关注的反馈。Dashboard 看到的是 request。我们看到的是趋势。