Vercel BotID lets you verify that each request to your AI endpoints comes from a real browser before any inference runs. Working as an invisible CAPTCHA, it attaches a client-side challenge to requests on the routes you protect, and a server-side checkBotId() call classifies each one, so automated clients are turned away before they reach your model. Running it on every request, rather than once per session, means an attacker can't bypass it once and reuse that access across thousands of stolen calls. That difference is what kept Nous Research’s chat app online when a coordinated attack spiked its traffic by 3,000% while inference stayed flat.
This guide walks you through installing BotID, declaring an AI route on the client, and gating that route with checkBotId() on the server so inference runs only for verified requests. You'll also set detection levels per route, enabling Deep Analysis on your highest-value endpoints and basic checks elsewhere, and learn how to let legitimate automation through with a Vercel WAF bypass rule.
Before you begin, make sure you have:
- A JavaScript project deployed on Vercel
- An AI endpoint that accepts frontend requests, such as a route built with AI SDK
- A Pro or Enterprise plan to use Deep Analysis (Basic is available on all plans)
Add BotID to your project:
Wrap your Next.js config with withBotId. This sets up proxy rewrites so that ad-blockers and third-party scripts can't weaken BotID's protection:
For Nuxt, SvelteKit, and other frameworks, the setup follows a similar pattern. See the BotID getting started guide for the per-framework versions.
Call initBotId() during client initialization and list the AI routes you want to protect. BotID uses this list to attach challenge headers to matching requests. If a route isn't declared here, its requests arrive without those headers, so checkBotId() has nothing to verify and treats them as bots.
For Next.js 15.3 and later, use instrumentation-client.ts:
On earlier versions of Next.js, mount the <BotIdClient /> component in your root layout head instead, passing the same protect array.
Call checkBotId() inside the route handler, before the AI call runs. This is the load-bearing step: it returns a classification for the request currently being served, so a blocked request never reaches your model.
Placing the check before runInference means you incur the inference cost only for verified requests.
Basic validation catches many less sophisticated bots and runs free on all plans. For high-value AI routes, enable Deep Analysis, which uses a Kasada-powered machine learning model to analyze thousands of client-side signals.
Because Deep Analysis learns and adapts in real time, it can detect coordinated attacks that initially appear as legitimate traffic. In one incident, it traced a 500% traffic spike to a new bot network by correlating identical browser fingerprints cycling across proxy nodes. It then reclassified and blocked those sessions within roughly 10 minutes, without any manual intervention. For the full breakdown, see how BotID Deep Analysis caught a sophisticated bot network in real time.
Visit the Bot Management page in your project settings, then click the Configure button to open the configuration settings and enable Deep Analysis.
This feature is available for all customers on Pro and Enterprise plans. Only requests that invoke checkBotId() are charged, passive page views are not.
- Run the check before inference: Keep
checkBotId()ahead of the model call in your handler, so a blocked request never costs you a token. - Set detection levels per route: Use
advancedOptions.checkLevelto applydeepAnalysisto your most sensitive routes andbasicelsewhere. ThecheckLevelmust be identical in your client and server configurations for each route, or verification will fail. This is available inbotid@1.4.5and later.
Blocking based on isBot alone also blocks legitimate automated agents, such as crawlers (e.g., Googlebot) and AI assistants (e.g., ChatGPT). To let specific agents through, use the verified-bot fields that checkBotId() returns along with isBot.
Vercel identifies these agents from its verified bot directory and returns isVerifiedBot, verifiedBotName, and verifiedBotCategory, so you can allow an agent like ChatGPT Operator while still blocking everything else.
For a trusted service that isn't in the verified bot directory, add a bypass rule in the Vercel WAF rather than removing protection from the route. See Handling Verified Bots for the full list of agents and categories.
Confirm the route is declared in your client protect array with a matching path and method. BotID only attaches challenge headers to declared routes, so an undeclared route has nothing for the server to verify.
BotID runs JavaScript in the browser session and sends headers to the server, so a direct request from curl or a browser address bar is treated as a bot in production. To test a protected route, make a fetch request from a page in your own application.
Local development returns isBot: false unless you set the developmentOptions option on checkBotId(). See Local Development Behavior in the BotID docs for instructions on simulating bot traffic.
Vercel BotID is an invisible CAPTCHA that confirms a request comes from a real browser before any inference runs. It attaches a client-side challenge to the routes you protect, then a server-side checkBotId() call classifies each request and turns away automated clients before they reach your model. Because the check runs on every request rather than once per session, an attacker can't bypass it once and reuse that access.
There are four steps. Install the botid package, wrap your framework config with withBotId, declare the route on the client with initBotId(), then call checkBotId() in your route handler before the model runs. Keeping the check ahead of the inference call means a blocked request never costs you a token.
No. The detection runs asynchronously inside the client session, so it doesn't block page loads or add noticeable latency for real users. The script that gathers browser signals is lightweight, and on the server checkBotId() only reads the verdict that's already attached to the request, so your handler isn't waiting on a separate analysis step. Since the check runs before inference, it can lower your overall costs by stopping bot requests before they trigger an expensive model call.
No. Basic validation runs free on all plans and catches many less sophisticated bots. Deep Analysis, which uses a Kasada-powered machine learning model to read thousands of client-side signals, is available on Pro and Enterprise plans. You're only charged for requests that invoke checkBotId(), not for passive page views.
Use the verified-bot fields that checkBotId() returns alongside isBot. Check isVerifiedBot and verifiedBotName to allow a known agent, such as ChatGPT Operator, while still blocking everything else. For a trusted service that isn't in Vercel's verified bot directory, add a bypass rule in the Vercel WAF rather than removing protection for the route.
This is expected. BotID runs JavaScript in the browser session to send challenge headers to the server, so a direct request from curl or a browser address bar has no headers and gets treated as a bot in production. To test a protected route, make a fetch request from a page inside your own application.