Vercel BotID is an invisible bot-detection product built directly into Vercel's hosting platform, powered by Kasada's detection engine under the hood, that lets any route deployed on Vercel add a bot challenge without integrating a separate anti-bot vendor — relevant to scrapers because Vercel hosts a large and growing share of the Next.js and AI-app sites a scraping operation is likely to target.
A developer wraps specific routes with a server-side checkBotId() call and attaches a client-side challenge script to the pages that call them; only declared routes carry the check, so an undeclared route has nothing to verify against. There's no visible CAPTCHA or interstitial in the normal flow — classification happens from passive signals the client-side script and the server call collect together, the same no-visible-challenge approach Cloudflare Turnstile and other modern products favor over older checkbox-style CAPTCHAs.
An optional "Deep Analysis" tier adds a heavier machine-learning classification pass for traffic that looks more sophisticated than the baseline check can confidently resolve — Vercel's own documentation states this tier is powered by Kasada, the vendor already covered in this glossary for its Forrester-Leader-tier bot-management product, so a site using Deep Analysis is effectively running Kasada's detection logic routed through Vercel's platform rather than a direct Kasada integration.
Because BotID ships as a platform feature rather than something a site owner has to separately contract and configure, it lowers the bar for any Vercel-hosted site — including ones with no dedicated security budget — to add real bot detection, unlike the self-selection effect of a site owner explicitly shopping for and deploying Cloudflare or DataDome. A target being hosted on Vercel no longer implies weaker anti-bot coverage than one that invested directly in a dedicated vendor.
Testing gotchas worth knowing: requests made with curl or typed directly into a browser's address bar are treated as bot traffic in BotID's production classification by design, and local development returns a non-bot result unless the developer explicitly opts into testing the real classification path — worth knowing before concluding a BotID-protected endpoint is or isn't currently challenging a given request pattern.
How Crawlora handles this
Crawlora's browser-rendering and residential-IP infrastructure is built to clear exactly this class of invisible, passive-signal bot check — Kasada-class detection, whether run directly or through a platform integration like Vercel's — the same anti-detect stack this glossary covers for Cloudflare, Akamai, DataDome, and PerimeterX applies here too.
Glossary
FAQ
Not exactly — it's Vercel's own bot-check feature built into its hosting platform, but its optional Deep Analysis tier is explicitly powered by Kasada's detection engine, so a site using that tier runs Kasada's logic routed through Vercel rather than a direct Kasada contract.
No — it's opt-in. A developer has to wrap specific routes with BotID's server-side check and client-side script; routes that don't declare it have no BotID protection at all.
Not reliably on its own — BotID classifies requests made via curl or a browser's address bar as bot traffic by design in production, so that alone doesn't distinguish a BotID-protected endpoint from one with no protection; you'd need to compare behavior across a real browser session too.
Beyond Vercel BotID, Crawlora's own docs cover the rest of the stack — browse the APIs, test a request in Playground, and move from scraping infrastructure work to production data workflows.