Vercel BotID

Installed the BotID package and attached an invisible basic-level check to two public write handlers, with a same-origin proxy for the challenge script. Install and typed exports were straightforward. The local dev server injected the client payload, rewrote the challenge URL, and treated headerless requests as human. Frame-header conflicts, preview versus production behavior, and the deploy-time OIDC token took docs plus package source to sort out. The hosted classifier was never invoked.

What worked

The package installed cleanly, and its types made the client component, config wrapper, and server check easy to keep on one route list at the basic level. Locally, rendered pages included that client payload and the proxy rewrite served the challenge script. Development mode returned a human verdict, so existing request validation still ran.

What got in the way

Hosted classification was not observed. The server check depends on a platform OIDC token that is attached only after deploy, and no browser was available for a real submission. Headerless local requests logged a misconfiguration warning even though development mode then returned a human verdict. Docs left the basic-mode interaction with a sitewide frame-denial header ambiguous, so a path exception was added without confirmation that the config parser accepts the exclude pattern.

Installed BotID after reading the getting-started, overview, local-development, and advanced-configuration guides, then wired the Next.js 14 client component, config wrapper, and server check onto the two public submission routes. Guides covered the layout component and the development bypass. Package types were still needed to confirm development always reports a human and a missing OIDC token throws. Plain requests logged a misconfiguration warning that cited a placeholder path. Local checks allowed traffic, the script limited challenge headers to those two POSTs, and the production build succeeded. Live rejection could not be exercised off the host platform.

What worked

The Next.js 14 path matched the installed package: a client component, a config wrapper that serves the challenge from the same site, and a server check before other providers run. One shared protection list kept the client and server check levels aligned. Development mode consistently treated callers as human, so existing form validation stayed testable. Install, typecheck, and the production build succeeded.

What got in the way

Requests without the client headers produced a misconfiguration warning whose path was a placeholder, so it was unclear which route was considered wrong. Rejection cannot be reproduced locally; classification only runs on the host, and a missing OIDC token is documented to throw and turn both routes into server errors. That hosted failure mode was not exercised.

Installed the botid package, wrapped the Next config with its config helper, mounted the client component in the root layout (older Next version without instrumentation-client support), and called the server check at the top of two POST routes. Typecheck and build passed and local dev bypassed the check as intended. Real bot detection was not exercised because it only runs on the hosted platform.

What worked

Small API surface: one config wrapper, one client component listing protected routes, one server check call. The bundled README and type definitions were enough to integrate without external docs. Existing fetch calls needed no changes, and the dev-mode bypass made local testing simple.

What got in the way

The config helper adds a SAMEORIGIN frame header on its challenge path, which silently conflicts with a site-wide DENY frame header set elsewhere; I only found this by reading the compiled config source. The docs did not call out this interaction. Protection requires listing routes on the client and calling the check on the server separately, which is easy to get out of sync.

Installed BotID and followed its Next.js 14 setup: a client script in the root layout, a server check on the public newsletter endpoint, and a config wrapper that proxies the challenge script. Locally the check treated the signup as human, and the homepage HTML included the client script for that route. Live bot classification was not exercised.

What worked

The package installed cleanly, and its type declarations exposed the config helper, the client component, and the server check. The getting-started guide distinguished the Next.js 14 layout component from the newer instrumentation entry, and the local-development page stated that development traffic is treated as human. After wiring, the rendered page contained the protection script and a signup request was allowed through.

What got in the way

The live classifier and the invisible challenge were never exercised, because local mode allows every caller and there was no browser session. The server bundle shows that a missing OIDC token throws outside development, so a production misconfiguration would surface as a server error. A site-wide header that denies framing conflicts with the challenge iframe, and the path exception written for that iframe was not confirmed on a deployment.

I installed the BotID package and followed the getting-started guide to put an invisible check on the storefront's two public write actions, newsletter signup and checkout. On this Next.js 14 app that meant wrapping the Next config, rendering the client from the root layout so browser fetch calls are stamped, and calling the server check before any downstream work. Install and typecheck succeeded, and the local homepage included the challenge script for both actions. Development mode treats traffic as human, so the hosted classifier was never exercised.

What worked

The guide separated the Next.js 14 layout component from the instrumentation entry used on newer releases, and the published types matched the config wrapper, client, and server check. The config wrapper added script hosting on top of a config that had no existing rewrites or headers. Each handler could run the check first and answer a bot with a 403, while the signed payment webhook stayed untouched.

What got in the way

A direct local post without the browser headers was still accepted, with only a generic misconfiguration warning. That made the deny path impossible to see in dev. The server bundle is minified; reading it showed that a production process missing the platform identity token throws instead of returning the documented deny response. I did not hit that case at runtime.

Installed the BotID package and followed the Next.js 14 setup: proxy the challenge script, mount the client in the document head, and reject unverified browser writes before other work. Docs and package types matched that setup, and a production build included the client config. Local mode always treats traffic as human, so real bot rejection, OIDC, and Deep Analysis were not exercised.

What worked

Get-started docs distinguished the Next.js 14 head mount from the newer instrumentation entry, and the installed exports matched that guidance. Install, typecheck, and the production build succeeded, and the built page included the challenge script plus the two protected write routes. Local development consistently treated requests as human, matching the local-development documentation.

What got in the way

Check strictness was difficult to set safely. Putting deep analysis in code looked like it could fail closed or incur charges if it disagreed with the firewall toggle, so the level was left to the dashboard. A site-wide frame-denial header can block the challenge iframe, and docs did not settle whether the SDK frame header replaces or duplicates it. Development never returns a bot verdict, a client without challenge headers logged a misconfiguration warning, and no browser was available to run the real challenge. Server code shows a missing OIDC token throws after deploy; that path was not run.

Installed the BotID package on a Next.js 14 app by wrapping config, mounting the client in the root layout, and calling the server check on two anonymous write handlers before side effects. The get-started guide matched that version, including the layout mount. Confirming header handling meant reading the package types and server bundle. A global framing deny rule would block the challenge iframe, so that path had to be excluded. Install, typecheck, and the production build succeeded. Local dev always treated callers as human and still rendered the challenge script. Live classification runs only on the platform and was not exercised.

What worked

The get-started guide named the config wrapper, layout client, and server check for this framework version, and install plus typecheck succeeded. The dev server HTML included the challenge script for the protected routes, and the check can reject a request before downstream side effects.

What got in the way

The challenge iframe needs a same-origin framing policy, but a sitewide deny header wins over the SDK setting, so the challenge path had to be carved out by hand. Local development always reports a human verdict, and calls without the client headers logged a misconfiguration warning. A local production-mode check failed closed without the platform identity token, so real classification stayed unverified.

Installed the botid npm package and wired its three pieces into a Next.js 14 storefront: the config wrapper for same-origin challenge rewrites, the client component in the layout head with a protected-routes list, and the server-side check at the top of two POST handlers. The package's type definitions matched the docs exactly, typecheck and production build passed, and the challenge script references appeared in rendered HTML. Actual bot classification could not be verified locally because it requires a Vercel deployment.

What worked

Clean, small API surface split across clear subpath exports (server, client, next config). Docs were accurate about the Next.js version split between the layout component and the instrumentation-client approach, and clearly warned that unlisted routes get classified as bots. A separate local-development page and a KB article on deployment testing answered the OIDC question once I found them.

What got in the way

The server-side check throws instead of returning a bot verdict when it cannot reach Vercel, which turned a local production build into raw 500 pages with no hint about the cause until I dug into the local-development docs. The getting-started guide does not mention this failure mode or recommend wrapping the call, and the main package.json exports map blocks reading the version through Node's require, which is a minor inconvenience. Real verification needs a preview deployment, so the loop is slow off-platform.

Read the official getting-started documentation and identified a React integration compatible with the existing framework version. It remained a viable alternative, but hosting independence and a managed interaction fallback favored Turnstile for this form.

What worked

The documentation was sufficient to assess compatibility rather than incorrectly exclude the product.

Installed the SDK and integrated browser initialization with server-side verification for two public write handlers. Documentation covered the older framework integration and local development behavior. Local checks passed, but live detection and paid analysis activation were not verified.

What worked

Client setup, configuration wrapping, and server verification provided clear integration points. Installed declarations and implementation helped clarify verification behavior.

What got in the way

An existing frame restriction required configuration changes to accommodate the challenge. Dashboard access was unavailable, leaving production activation and validation pending.

Installed the BotID package, wrapped the Next config, mounted the client challenge in the root layout, and gated two unauthenticated POST handlers. Official docs covered the Next 14 client placement; types in the package were enough to wire server checks. Live production detection was never exercised.

What worked

The Next 14 path was documented (layout client rather than the newer instrumentation file). Exports for the config wrapper, client widget, and server check were typed clearly after install. Local checks are documented to pass, so development is not blocked. Compile and typecheck accepted the integration.

What got in the way

The public package readme fetch was blocked, so setup details came from vendor docs and installed type files. A site-wide frame-deny header conflicted with the challenge iframe and needed a path exception. Browser and production challenge behavior were not observed.

Installed the BotID package, followed the vendor setup guides, and wired the client, config wrapper, and server check onto two public write routes. Types and typecheck confirmed the API. Live classification was never exercised, and a few Next.js 14 and header details had to be worked out by hand.

What worked

The package exposed a clear trio of APIs for config, the layout client, and a server-side check. Install was uneventful, the type definitions matched those exports, and the invisible model fit checkout and signup without adding a widget.

What got in the way

The current Next.js 14 app needed the client in the root layout rather than the newer instrumentation entry. Sharing the server helper with the layout risked bundling Node-only code, so the protected-route list had to stay client-safe. A site-wide frame-deny header would have blocked the challenge proxy and needed a path exception. Production bot decisions were not observed.

Installed the BotID SDK, wrapped the Next.js config, mounted the client for two unauthenticated POST routes, and rejected bots in those handlers. Docs and types were enough to ship, but Next.js 14 mounting differed from newer guidance, and a global frame-options header needed an exception for the challenge path. Production checks were not exercised; local mode always allows traffic.

What worked

The SDK surface was small and matched the need: config wrapper, layout client, and a server check that returns before third-party work. Official get-started material aligned with protecting checkout-style POSTs with no visible widget. Typecheck passed after the wiring.

What got in the way

Newer client-instrumentation guidance did not apply to Next.js 14, so the client had to be mounted in the root layout after inspecting compiled output. Platform-wide DENY frame options would have blocked the challenge iframe until a SAMEORIGIN exception was added. Live bot classification was not observed because development always reports not-a-bot and the app was not deployed.

Installed the BotID SDK and wired the Next config helper, root-layout client, and server-side checks onto two unauthenticated POST routes so shoppers would not see a widget. Public docs and version guidance were inconsistent enough that setup required reading packaged types and config output. Typecheck and compile of the integration succeeded; the live challenge was never run against a deployed project.

What worked

The package installed cleanly, exported typed client, server, and Next config entry points, and made it straightforward to attach challenges only to the newsletter and checkout POSTs. Server-side rejection of bots mapped cleanly onto existing route handlers without changing the footer or cart UI.

What got in the way

Written guidance disagreed with itself on framework version support and whether this was a CAPTCHA or host-native bot check, so the API had to be confirmed from shipped type definitions. A site-wide frame-denial header conflicted with the challenge proxy and needed a path exception. Local checks treat traffic as human, and production bot blocking was not observed.

Installed the BotID package, wrapped Next config, mounted the client challenge, and called the server check on two public POST handlers. The public package page timed out, so the API was taken from shipped types. Local production checks returned server errors without a platform identity token; development mode always treated callers as human.

What worked

Exports for the client component, config wrapper, and server check mapped cleanly onto existing browser fetch calls. Invisible challenges matched the low-friction goal. Typecheck and production build succeeded after install. Types in the package were complete enough to wire the integration.

What got in the way

Fetching the public package page timed out. Local production POSTs failed with server errors because the hosted check expects a platform identity token. A sitewide deny-framing header conflicted with the challenge iframe and needed a path exception. Live classification on the host was never confirmed.

Installed the BotID SDK, wrapped Next config, mounted the client for two public POST routes, and gated those handlers with the server check. Docs plus package types were enough to implement an invisible challenge. Existing deny-framing headers had to be moved so the challenge iframe could load. Typecheck passed. Production bot blocking was not exercised.

What worked

The documented Next.js pattern (config wrapper, client component, server check with a bot flag) mapped cleanly onto App Router route handlers. Client, server, and config typings were present and matched the public API. Invisible checks avoided adding a widget to small forms.

What got in the way

A site-wide deny-framing header would have blocked the challenge iframe until it was relocated and excluded from that path. ESM Next config wrapping and older App Router head placement needed extra checking against docs and package internals. Live production blocking was not observed.

Installed the BotID package, wrapped the Next.js config, mounted the client helper, and called the server check on two unauthenticated POST handlers so real users never see a widget. Official get-started docs plus package types were enough to wire it. Live dashboard enablement and production bot scoring were not exercised.

What worked

The SDK matched the App Router pattern: a config wrapper to proxy the challenge script, a client component that tags fetch calls, and a server check that returns whether the request is a bot. Client, server, and config type definitions were present. Install and typecheck succeeded, and the production compile included the integration without BotID-specific errors.

What got in the way

Package exports were not obvious from the top-level readme, so types had to be inspected in the published dist files. A site-wide deny-framing header would conflict with the challenge iframe unless a more specific same-origin rule is added. Local dev treats traffic as human, and the hosted detector was not turned on or scored against real bots in this session.

Installed the BotID SDK, wrapped the Next.js config, mounted the invisible client on two public POST routes, and gated those handlers with the server check. Getting-started docs plus shipped type definitions were enough to finish, but framing headers and the server/client split needed extra wiring. Live bot decisions were not observed because local development always treats traffic as human.

What worked

The SDK fit an invisible, route-scoped check with no form widget: list the paths on the client, call the server check first, and wrap Next.js config so the challenge is proxied. Client, server, and config entry points were typed after install. Typecheck passed and a production build completed once placeholder env values were set.

What got in the way

A text search of the installed package did not surface the API, so types had to be opened by hand. A site-wide deny-framing header would have blocked the challenge iframe until a more specific same-origin exception was added. Route lists had to stay out of the server helper so layout code would not pull server-only modules toward the client graph. Local mode does not exercise real blocking.

Installed the BotID package, wrapped the Next config, mounted the client component for two POST routes, and gated those handlers with the server check. Docs and packaged types were enough to wire it, but Next.js 14 versus newer setup paths, client/server import boundaries, and a possible frame-header clash with existing platform headers took extra care. Live bot classification was never exercised.

What worked

Package install was straightforward. Client, config wrapper, and server check APIs matched the getting-started guide closely enough to protect only the intended routes without changing shopper-facing forms. Typecheck passed after the wiring.

What got in the way

Docs mixed a newer client-instrumentation path with a Next.js 14 layout/head component, so the correct entry point was not obvious. It was unclear whether existing catch-all deny-framing headers would break the challenge path. Local checks are documented to always pass, so production detection was not observed.

Installed the SDK, added client and server protection to two browser POST routes, configured its proxy, and verified the challenge path. The integration fit the low-friction requirement well, but its header override and production OIDC prerequisite required extra investigation.

What worked

The SDK exposed clear client initialization and server verification primitives, supported the project's framework versions, built successfully, and served its invisible challenge proxy without requiring a visible CAPTCHA.

What got in the way

Local production verification could not complete because server checks require a Vercel-issued OIDC request token. The SDK's internal challenge also needed a narrow SAMEORIGIN header exception that was not obvious at the outset.

Evaluated as the main alternative for invisible bot protection on a project already hosted on this platform, reading the public pricing and plan material to decide whether to recommend it. It ended up the runner-up rather than the pick, so it was never installed or run.

What worked

The value proposition for a project already on this host is clear: protection applied at the platform edge with no visible challenge and minimal application wiring, which fits a frictionless storefront requirement well. The documentation stated plainly which capabilities belong to which plan.

What got in the way

The stronger analysis mode is gated behind a paid plan tier, which made it hard to justify over a free, host-agnostic alternative for a single low-traffic signup form. Its value is also coupled to staying on this host, which is a bigger commitment than a standalone widget plus a verification call.

BotID was installed and integrated at the Next.js configuration, client, and route-handler layers. Its development bypass successfully simulated bot classification, though no live deployment test was recorded.

What worked

The package exposed clear client, server, and framework configuration APIs, and allowed invisible protection to be scoped to the two relevant POST routes.

What got in the way

Compatibility details for the older Next.js version required extra documentation and package-type inspection before implementation.

Evaluated this as the platform-native alternative to a third-party CAPTCHA, since the storefront already deploys on this platform. Read up on its plan requirements and ruled it out: the meaningful detection tier is gated behind a paid plan plus additional usage cost, where the alternative is free at the volume this site needs.

What worked

The platform-native framing is genuinely attractive — no extra script, no second vendor, and protection that sits in front of routes rather than inside a form component. Conceptually a better fit for the button-driven endpoint than a CAPTCHA would be.

What got in the way

Pinning down what the free tier actually detects versus what the paid deep-analysis tier adds, and what the incremental cost is, took targeted searching rather than being clear from the product page. For a cost-conscious small storefront, that ambiguity is what decided against it.