What is the Vercel Security Checkpoint and how to recognise it
The Vercel Security Checkpoint is the interstitial page Vercel serves in front of sites that sit behind Vercel Firewall or Attack Mode. A visitor has to complete a security challenge before the site loads, while known bots such as search engines and webhooks pass through. Which sites and routes show it is the site owner's choice, so it can appear on one route and not on the next.
Do not confuse it with Vercel BotID. BotID is an invisible, client-side challenge that a site validates on its own server for sensitive routes, and it shows no page at all. The checkpoint is the visible interstitial, and the _vcrcs cookie addresses only that one. If a route is also gated by BotID, clearing the checkpoint may not be enough.
Solving the checkpoint gives you the _vcrcs cookie value, a JWT-shaped string. It is meant to be replayed on the protected origin, not typed into a form.
Extension, API or automation?
There is no browser extension: SurSolver is an HTTP API. For this type you send the URL of the challenged page, your proxy details and optionally a user agent; the solve runs on SurSolver's side and you get the cookie data back. Your own client then replays it.
That fits curl or requests for a server-side job, or Playwright, Puppeteer and Selenium when a real browser has to carry the session. There is nothing to compute in the page and no script to inject.
How to find the parameters
There is no sitekey for this type. The one required value is the page URL: the full address of the page that shows the checkpoint, copied from the address bar with its path and query string.
Proxy details are required. The user agent is optional; if you send one, it should be the user agent of the client that will replay the cookie.
Vercel itself says Attack Mode challenges all traffic initiated by web browsers, API traffic included, and that standalone APIs and non-browser clients may not be able to pass challenges and could be blocked. If a script that calls a Vercel-hosted API gets blocked, this is the likely reason.
Where the cookies go
The result has the keys token, cookies and userAgent. Replay the _vcrcs value as a cookie of that name on the target origin, then request the protected page or API from that session.
Vercel does not publish how the cookie is bound or how long it lasts. The safe approach is to keep the proxy and the user agent consistent with the solve, and to treat any reuse as unverified: when the checkpoint shows up again, solve again.
Common mistakes
The first mistake is solving the wrong product. BotID is invisible and checked by the site's own server; the checkpoint is the visible interstitial. A _vcrcs cookie does not help against BotID.
The second is creating a task without proxy details. This type requires a proxy. The third is replaying from a different network or with a different user agent than the solve used; the binding is not documented, so keeping them the same is the cautious choice.
Finally, do not assume the checkpoint is everywhere on a site. Site owners can challenge arbitrary traffic with firewall rules, so a URL that is challenged today may not be tomorrow. Send the exact URL that shows the checkpoint, and confirm it is there before you create a task: a task is charged when it is accepted, and a task that finishes as failed automatically returns its original charge once.
Solve it with SurSolver
Send the challenged page URL, your proxy details and, optionally, your user agent to createTask with the task type VercelToken, then poll getTaskResult until the status is ready. The result keys are token, cookies and userAgent; replay the _vcrcs value from them. The accepted names and parameters are listed by the public catalog (GET /v1/task-types).