What is Prosopo Procaptcha and how to recognise it
Procaptcha is the widget from Prosopo, positioned as a privacy-focused, open-source alternative to reCAPTCHA. A site places it in front of a form submission and works in tiers: a frictionless background check, a proof-of-work step where the browser solves a small computation, and an image selection shown only when the visitor looks suspicious.
A page that uses it contains a container element with the procaptcha class and a data-sitekey attribute, and loads the script from js.prosopo.io/js/procaptcha.bundle.js. Either of those two signs tells you the page is Procaptcha and nothing else.
Solving the widget returns a single signed token. The same token task covers all three tiers, so the tier the visitor would have faced does not change what you send or what you receive. The site verifies the token server-side against Prosopo with its own secret key.
Extension, API or automation?
You use SurSolver by sending two HTTP calls, createTask and getTaskResult; there is no extension and nothing to add to a browser. Procaptcha needs only a URL and a sitekey, so a short script is usually all you need, whether it is a bare HTTP client or a Playwright, Puppeteer or Selenium session that already holds the form.
For Procaptcha, the right choice depends on how the site checks the token. If the form is a plain POST, an HTTP client is enough: collect the sitekey, get the token and send it in the procaptcha-response field. If the site renders the widget with JavaScript and reads the result through a callback, drive the page with automation so the token reaches the callback. The API never visits the target site for you; your code collects the parameters and your code submits the result.
How to find the sitekey
Open the protected page, press F12 and search the Elements panel for data-sitekey. The value of that attribute on the procaptcha container is your sitekey.
If the widget is rendered from JavaScript instead of the HTML attribute, the same key is passed as the siteKey option of the procaptcha.render(...) call. Read both the DOM attribute and the render call, because the page may use either. As a cross-check, reload with the Network tab open and look for requests to prosopo.io or procaptcha.io: they carry the sitekey, and some pages also send it in a Prosopo-Site-Key request header.
The page URL you send must be the full URL of the page that loads the widget, including the query string where the widget is bound to a path. It has to match the protected domain, otherwise verification fails. Only websiteURL and websiteKey are required; userAgent is optional.
Where the token goes
The token belongs in the form field named procaptcha-response, submitted together with the protected form. The site then verifies it with Prosopo. Where a page does not use a plain form, call the callback the page passed to the widget with the token instead, or set the hidden payload the widget would have inserted and submit.
In a browser-automation script, set the field value with page.evaluate() and then click submit. When the solution includes a user agent, use the same one for the submission. Tokens are short-lived, so submit right after the task becomes ready.
Common mistakes
The first is ignoring IP validation. Some sites check that the IP which solved the widget is the IP that submits the token. When a valid-looking token is rejected while a manual flow works, switch from the proxyless task to ProsopoTask, send your own proxy, and submit through that same proxy. Start with proxyless and move to the proxy variant only when that happens.
The second is taking the sitekey from the wrong place. Each widget has its own sitekey and secret pair, so a key harvested from another site does not work here, and a mismatched domain fails verification.
The third is session binding. Sites that use Prosopo's session correlation tie each token to a session id rendered in their own widget, and a token minted outside that session verifies as false. A hardened site like that can reject third-party tokens even when everything else is correct.
The last one is waiting too long. Tokens are short-lived: solve inline with the request you are about to make, then submit immediately.
Solve it with SurSolver
Send the page URL and the sitekey to createTask with the task type ProsopoTaskProxyless (or ProsopoTask when you want to solve through your own proxy), then poll getTaskResult until the status is ready. The solution carries the token and, when the solver reports one, the user agent it was earned with. A task is charged when it is accepted, and failed tasks automatically return their original charge once; the accepted names and parameters are listed by the public catalog (GET /v1/task-types).