在 Postman 中测试 solvethree

1. 1.

   导入下载的 JSON

   在 Postman 中选择“导入”，然后选择集合文件。其中包含“创建任务”和“获取任务”请求，两者均继承 Bearer 授权并使用变量占位符。

2. 2.

   检查站点的配置文件

   你的工作区需要有适用于目标主机名的有效配置文件。测试前请在控制台中配置；发送主机名和操作不会创建配置文件。参见站点配置文件设置。

3. 3.

   配置私密环境值

   为本次测试创建并选择一个环境。以私密方式填写以下值，包括所有代理凭据。不要将密钥等敏感信息直接放入集合，也不要导出已填入的敏感信息。

4. 4.

   配置 Bearer 授权

   在集合级别选择 Bearer Token，并引用包含工作区 API 密钥的私密环境变量。让两个请求均保持继承授权的设置。API 要求使用 Authorization: Bearer，后接该密钥。

打开“创建任务”。它会向 https://api.solvethree.com/v1/tasks 发送 POST，请求体为原始 JSON，内容由所选环境填充。

{
  "site": "{{SITE}}",
  "action": "{{ACTION}}",
  "proxy": "{{PROXY}}",
  "requestId": "{{REQUEST_ID}}"
}

此请求默认使用 reCAPTCHA Enterprise v3。不要添加 type 或 url 字段。它提供单个 proxy，因此不要再添加 proxyCandidates：这两个字段必须且只能提供一个。

发送前设置 REQUEST_ID，然后点击一次“发送”。先检查 HTTP 响应。如果响应不成功，请检查请求错误，而不是将响应体视为成功的任务响应。应修正无效输入，而不是反复原样发送。

创建响应成功时，将返回的 id 复制到私密的 TASK_ID 环境值中。不要仅为了检查进度而再次点击“创建任务”。

打开“获取任务”，确认 TASK_ID 包含返回的任务 ID。此请求在同一 API 上使用 GET /v1/tasks/:id。手动发送请求，检查 HTTP 响应，然后查看任务的 status。

仅有 HTTP 200 或 201 并不表示解决结果已就绪；只有 status: ready 才表示就绪。本手动测试检查的是任务创建和获取，而非目标网站是否接受结果。

如果你继续将 reCAPTCHA 令牌提交到其预期目标，请使用返回的 userAgent 和 secChUa 浏览器身份，以及成功求解时使用的代理。不要切换 IP，也不要混用无关的浏览器身份。已就绪的令牌仍可能被目标拒绝。

连接超时并不能证明创建失败。如果已有任务 ID，请获取该任务。如果始终未收到 ID，请使用相同的 REQUEST_ID 和未更改的任务输入重新发送“创建任务”请求。这样会恢复现有任务，而不是另建一个逻辑任务。

不要仅因为响应丢失就生成新的 REQUEST_ID。复用 ID 时使用不同的任务输入会导致冲突；只有明确要开始新任务时，才使用新 ID。