Use the CAPTCHA task API in Make

First, set up an active profile for the target hostname in your workspace. Sending site and action doesn’t create one. See site profile setup if the target isn’t configured yet.

1. 1.

   Configure HTTP v4 authentication

   Choose Authentication type API key and create a Credentials keychain. Set Key to Bearer followed by a space and your workspace API key, placement to In the header, and parameter name to Authorization. Restrict Allowed service origins to https://api.solvethree.com. Keep the key in the keychain rather than passing it through scenario data.

2. 2.

   Enter the request settings

   Use the method, URL, query parameter, header, and JSON body shown below. Enter each in its corresponding module field. Only the contents of body belong in JSON request content; the complete example is explanatory configuration, not an importable Make blueprint.

{
  "method": "POST",
  "url": "https://api.solvethree.com/v1/tasks",
  "query": {
    "waitMs": "0"
  },
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "site": "accounts.example.com",
    "action": "login",
    "proxy": "http://USER:PASSWORD@PROXY:PORT",
    "requestId": "one-stable-id-for-this-logical-job"
  },
  "authentication": {
    "type": "API key",
    "Key": "Bearer YOUR_PRIVATE_WORKSPACE_KEY",
    "API key placement": "In the header",
    "API key parameter name": "Authorization",
    "Allowed service origins": [
      "https://api.solvethree.com"
    ]
  }
}

• Replace site with the configured hostname, not a full URL. Set action to the action used by the target flow.
• Replace proxy with your proxy URL. The request requires exactly one of proxy or proxyCandidates; the example uses a single proxy.
• Give each new logical job its own requestId, and retain it for recovery. The example value is a placeholder, not an ID to reuse across unrelated jobs.
• Don’t add type or url to this reCAPTCHA request. With recaptchaType omitted, it defaults to enterprise-v3.

After a successful create response, save the returned task ID against the logical job before doing more work. Add a separate HTTP request module to retrieve that task.

Handle non-success HTTP responses before routing on task status. An HTTP error isn’t the same as a task whose status is failed; don’t treat an unreadable or unsuccessful response as another pending result.

After GET succeeds, add a router with explicit filters on the returned status. Don’t send every successful HTTP response down the solution route.

Keep the unfinished filter explicit rather than making it a catch-all. A missing or unexpected status should be inspected, not silently polled forever. On the failed route, investigate the reported error before creating another task; unchanged invalid inputs won’t improve with retries.

A simple bounded design performs one GET per polling run. Save unfinished work somewhere the next run can read it; don’t rely on a task ID that exists only in the current execution.

1. 1.

   Choose the entry path

   If the job already has a task ID, go directly to GET. Only a new job without an existing task should enter the create path.

2. 2.

   End unfinished runs

   For pending or solving, retain the task ID and end the run. On resumption, retrieve that same ID. Mark terminal tasks as closed so later polling runs don’t process their results again.

3. 3.

   Bound any repeater

   If you add a repeater instead, give it a finite maximum count and repeat only GET for the saved ID. Prevent further polling or result handling after ready or failed. Reaching the repetition limit means stop and retain the ID, not create a replacement task.

For this reCAPTCHA request, the value to submit is solution.token, not the task ID. Use the returned userAgent and secChUa browser identity with the successful proxy when submitting to the intended target.

Don’t assume Make’s HTTP module can use the solver’s customer proxy for that final request. Hand the ready result to a client that supports the required proxy and browser identity. ready means the solution was generated; acceptance is determined by the target’s response to the subsequent submission.