Scarnox · Blog

Solving invisible PopularCaptcha: how it differs and what to send

Invisible PopularCaptcha looks like no captcha at all. There is no "I am human" box. The site calls PopularCaptcha from its own JavaScript, usually when the visitor presses submit, and shows a challenge only if it is unsure about the visitor. For an automation script the widget is harder to spot, but the solve is still one request.

Scarnox solves PopularCaptcha today, including the invisible variant. You set one flag, is_invisible, and send the same request you would send for a visible widget. Other captcha types are coming soon.

How to tell it is invisible

The widget has data-size="invisible".
The site calls the widget's execute() function in its own code.
There is a sitekey in the page, but no visible checkbox anywhere.

The configuration on the sitekey decides it, not the look of the page. If you are unsure, find the sitekey and check the widget options in the page's JavaScript.

What to send

Use the same endpoint and the same task type, and add is_invisible set to true:

{
  "captcha_type": "PopularCaptchaTaskProxyless",
  "site_key": "10000000-ffff-ffff-ffff-000000000001",
  "site_url": "https://example.com/login",
  "is_invisible": true
}

Send it with your key in the Authorization: Bearer header, as in every other example. The call blocks until the token is ready, with no polling. Use a timeout of about 185 seconds.

Handing the token back

Invisible integrations nearly always use a callback rather than a form field. The site passes a function name to the widget, either in the data-callback attribute or in the options given to render(). Call that function with the token, and the site's own code continues as if the visitor had passed the challenge:

await page.evaluate((t) => {
  document.querySelectorAll('[name="h-captcha-response"]').forEach((el) => { el.value = t; });
  const cb = document.querySelector("[data-sitekey]")?.dataset.callback;
  if (cb && typeof window[cb] === "function") window[cb](t);
}, token);

Setting the hidden field as well is harmless, and it covers sites that read the field on submit.

Timing matters more than usual

With an invisible widget the site decides when the challenge runs, and that is usually the moment the visitor submits. So solve at that moment, not earlier. The easiest pattern is to trigger the solve right before you press the button in your script, then call the callback and submit.

Tokens expire within about two minutes. A token fetched during page load and used a minute later is likely to be rejected.

Common mistake

Sending an invisible sitekey as a normal visible task can produce a token the site refuses. If the API returns a token but the site rejects it, check these in order:

Is is_invisible set to true?
Does the site call the callback, and does it do so before the form submits?
Is the site_url the page where the invisible widget runs?
If the site still refuses the token, the problem may be tied to the IP that solved it. Compare with proxy versus proxyless solving.

Testing an invisible flow safely

Invisible widgets are hard to test by hand, because the challenge runs only at submit and most of the time it passes without showing anything. Test in this order:

Confirm the solve returns a token with is_invisible set to true, using the smoke test from the free trial guide.
Trigger the site's callback yourself in the browser console with that token, and watch whether the form continues.
Submit the form from your script, and check the page that comes next.
Repeat the run from a second network, if you can, to confirm the token is not tied to the IP that solved it.

Keep the test on a form you own, or on a staging copy of the site you are allowed to test. Never run an invisible flow against a live account you do not control.

The order of events in one invisible submit

A working integration follows this sequence:

The visitor, or your script, fills in the form.
Your script reads the sitekey and the page URL from the page.
Your script calls the solve endpoint with is_invisible set to true and waits for the token.
Your script writes the token into the response field and calls the site's callback.
The site's code submits the form with the token attached.

If step 3 happens much earlier than step 5, the token may expire before the form submits. Keep the gap as short as possible.

When the site rejects an invisible token

A rejection is not always a problem with the token. Check these before you change the solve request:

The callback ran before the form submitted, not after.
The form reads the token from the field your script wrote to. Some sites use a different field for invisible widgets.
The request that carries the token came from the same session that loaded the page. Cookies from another session do not match.
The page did not reload between the solve and the submit, which would discard the token.

Only after these checks should you move to the proxy question. Most rejections come from the callback or the session, not from the IP.

Next steps

Start with free trial credit, no card needed: create an account and test an invisible sitekey on a page you own.