@botbye/nuxt

BotBye! integration for Nuxt applications.

Full documentation: https://botbye.com/docs/server-side/node-js/nuxt

Install

npm i @botbye/nuxt

yarn add @botbye/nuxt

Requires nuxt >= 3 as a peer dependency.

Package exports

The package exposes three entry points:

• @botbye/nuxt/server — server-side SDK: init, evaluate, dev, factory
• @botbye/nuxt/client — client-side utilities: initChallenges, runChallenge
• @botbye/nuxt/module — Nuxt module for automatic client-side initialization

Client-side integration

The @botbye/nuxt/client entry point provides utilities for initializing the BotBye client-side SDK and running challenge flows in the browser.

Using the Nuxt module (recommended)

Add the module to nuxt.config.ts to enable automatic client initialization and TypeScript support for useRuntimeConfig().public.botbye:

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ["@botbye/nuxt/module"],

  botbyeModule: {
    inject: true,
  },

  runtimeConfig: {
    public: {
      botbye: {
        // Use your client key
        clientKey: "00000000-0000-0000-0000-000000000000",
      },
    },
  },
});

When inject: true, the module registers a client plugin that calls initChallenges automatically using runtimeConfig.public.botbye.

Once the SDK is initialized, call runChallenge() anywhere in client-side code to acquire a token and pass it to your API:

import { runChallenge } from "@botbye/nuxt/client";

const onLoginClick = async () => {
  const token = await runChallenge();

  await $fetch("/api/login", {
    method: "POST",
    headers: {
      // "x-botbye-token" is an example — pass the token from wherever you store it
      "x-botbye-token": token,
    },
    body: { email, password },
  });
};

Manual initialization

If you prefer not to use inject: true, call initChallenges directly in a client-side Nuxt plugin:

// plugins/botbye.client.ts
import { initChallenges } from "@botbye/nuxt/client";

export default defineNuxtPlugin(() => {
  initChallenges({
    // Use your client key
    clientKey: "00000000-0000-0000-0000-000000000000",
  });
});

User identification

Call setUserId after a successful authentication to associate the current session with a user. This helps BotBye detect multi-account abuse.

import { setUserId } from "@botbye/nuxt/client";

const response = await login({ username, password });

if (response.userId) {
  setUserId(response.userId);
}

Configuration

Call init once at server startup with your server key. The recommended place in Nuxt is a Nitro server plugin:

// server/plugins/botbye.ts
import { init } from "@botbye/nuxt/server";

export default defineNitroPlugin(() => {
  init({
    // Use your project server-key
    serverKey: "00000000-0000-0000-0000-000000000000",
  });
});

init options

| Option | Type | Required | Description | |---|---|---|---| | serverKey | string | Yes | Server key from your BotBye project | | url | string | No | Override BotBye API endpoint (default: https://verify.botbye.com) | | logger.level | "error" \| "warn" \| "info" \| "debug" \| "log" | No | Log level (default: "info") | | logger.logger | TLogger | No | Custom logger instance implementing { error, warn, info, debug, log } | | timeouts.evaluate | number | No | Timeout in milliseconds for each evaluate call |

Usage

Call evaluate in API handlers or server middleware where bot protection is needed. It accepts an event object describing what you know about the request and the context around it, and returns a promise that resolves to a decision.

There are three event types — validate, risk, and full — each suited for a different layer of your application.

validate — edge-level bot check

Use at the outermost layer — server middleware or API handler — when you just want to know: was this request made by a bot? No user or domain context needed.

Event fields:

{
  type: "validate";

  request:
    // Option A: pass the H3Event object directly — SDK extracts everything automatically
    | { request: H3Event; token?: string | null }
    // Option B: construct request info manually
    | { ip: string; headers: Record<string, string>; requestMethod?: string | null; requestUri?: string | null; token?: string | null };

  customFields?: Record<string, string>;

}

The SDK extracts IP, headers, method, and URI from the H3Event object automatically. You can also pass request info manually — see Option B above. The token is a one-time token generated by the BotBye client-side SDK that contains information about the user's device. Pass whatever the client sent; if no token is received, the decision will be "BLOCK".

import { evaluate } from "@botbye/nuxt/server";

export default defineEventHandler(async (event) => {
  const result = await evaluate({
    type: "validate",
    request: {
      request: event,
      // "x-botbye-token" is an example — pass the token from wherever you store it
      token: getRequestHeader(event, "x-botbye-token"),
    },
  });

  if (result.decision === "BLOCK") {
    throw createError({ statusCode: 403, message: "Forbidden" });
  }

  // proceed normally
});

risk — domain-level risk scoring

Use inside API handlers that already know the user: auth, payments, account management, etc. The purpose shifts from "is this a bot?" to "is something suspicious happening for this user?" — credential stuffing, account takeover, account sharing, logins from a new geo.

Event fields:

{
  type: "risk";

  request:
    | { ip: string; headers?: Record<string, string>; requestMethod?: string | null; requestUri?: string | null; token?: string | null }
    | { request: H3Event };

  event: {
    type: string;   // e.g. "login", "password_change", "checkout"
    status: "ATTEMPTED" | "SUCCESSFUL" | "FAILED" | "UNKNOWN";
  };

  user: {
    accountId: string;
    username?: string | null;
    email?: string | null;
    phone?: string | null;
  };

  customFields?: Record<string, string>;
  botbyeResult?: string;

}

event and user are the key fields here — they define what action is being performed and who is performing it, which is what drives the risk score. ip is equally important: BotBye tracks which IPs access the account to detect patterns like account sharing, credential stuffing, and suspicious geo logins. Pass it directly as { ip }, or pass the H3Event object if that's more convenient.

import { evaluate } from "@botbye/nuxt/server";

// Inside an API handler, after a login attempt
async function onLoginAttempt({ ip, userId, email, loginSucceeded }) {
  const result = await evaluate({
    type: "risk",
    request: {
      ip,
      headers: {},
    },
    event: {
      type: "login",
      status: loginSucceeded ? "SUCCESSFUL" : "FAILED",
    },
    user: {
      accountId: userId,
      email,
    },
  });

  if (result.decision === "BLOCK") {
    // Lock account, trigger MFA, send alert, etc.
  }
}

Linking validate and risk events

When the same request is evaluated at two layers — for example, once at the edge in server middleware (type: "validate") and then again inside an API handler (type: "risk") — BotBye can link both events and display them as a single event in the dashboard.

Step 1 — server middleware (edge layer): run validate and capture botbye_result:

// server/middleware/botbye.js
export default defineEventHandler(async (event) => {
  const edgeResult = await evaluate({
    type: "validate",
    request: {
      request: event,
      // "x-botbye-token" is an example — pass the token from wherever you store it
      token: getRequestHeader(event, "x-botbye-token"),
    },
  });
  const edgeBotbyeResult = edgeResult.botbye_result;
  // Pass edgeBotbyeResult downstream — event context, shared state, a forwarded header, etc.
});

Step 2 — API handler (domain layer): pass it as botbyeResult in the risk call:

// server/api/auth/login.post.js
const riskResult = await evaluate({
  type: "risk",
  request: { ip },
  event: {
    type: "login",
    status: loginSucceeded ? "SUCCESSFUL" : "FAILED",
  },
  user: {
    accountId: userId,
    email,
  },
  botbyeResult: edgeBotbyeResult,
});

botbye_result is optional in the response — if it is absent, omit botbyeResult and the events will be recorded independently.

full — edge check and domain scoring in one call

Use when you have all context at once: raw request, token, user, and event. A login endpoint is a typical example — it receives the HTTP request and immediately knows the user and outcome.

Event fields:

{
  type: "full";

  request:
    | { request: H3Event; token?: string | null }
    | { ip: string; headers: Record<string, string>; requestMethod?: string | null; requestUri?: string | null; token?: string | null };

  event: {
    type: string;
    status: "ATTEMPTED" | "SUCCESSFUL" | "FAILED" | "UNKNOWN";
  };

  user: {
    accountId: string;
    username?: string | null;
    email?: string | null;
    phone?: string | null;
  };

  customFields?: Record<string, string>;

}

Equivalent to running validate and risk in a single call.

import { evaluate } from "@botbye/nuxt/server";

// server/api/auth/login.post.js
export default defineEventHandler(async (event) => {
  const { email, password } = await readBody(event);
  const user = await findUser(email);
  const loginSucceeded = user && (await checkPassword(user, password));

  const result = await evaluate({
    type: "full",
    request: {
      request: event,
      // "x-botbye-token" is an example — pass the token from wherever you store it
      token: getRequestHeader(event, "x-botbye-token"),
    },
    event: {
      type: "login",
      status: loginSucceeded ? "SUCCESSFUL" : "FAILED",
    },
    user: {
      accountId: user?.id ?? "unknown",
      email,
    },
  });

  if (result.decision === "BLOCK") {
    throw createError({ statusCode: 403, message: "Forbidden" });
  }

  // proceed normally
});

Response

evaluate always returns a Promise<TEvaluationResult>:

type TEvaluationResult =
  | {
      decision: "ALLOW" | "BLOCK" | "CHALLENGE";
      request_id: string;
      risk_score: number;
      scores: Record<string, number>;
      signals: string[];
      botbye_result?: string;
    }
  | {
      decision: "ALLOW" | "BLOCK" | "CHALLENGE";
      botbye_result?: string;
      error: { message: string };
    };

Check result.decision to decide how to handle the request:

• "ALLOW" — request appears legitimate, proceed normally
• "BLOCK" — bot or suspicious activity detected, block the request
• "CHALLENGE" — uncertain, consider issuing a CAPTCHA, MFA or additional verification step

When the response contains an error field, BotBye could not evaluate the request (e.g. invalid server key). In that case decision defaults to "ALLOW" so that a misconfiguration does not block real users — but you should monitor and fix the underlying error.

Response examples

Blocked (bot detected):

{
  "request_id": "f77b2abd-c5d7-44f0-be4f-174b04876583",
  "decision": "BLOCK",
  "risk_score": 0.95,
  "scores": { "bot": 0.95 },
  "signals": ["AutomationTool"]
}

Allowed:

{
  "request_id": "f77b2abd-c5d7-44f0-be4f-174b04876583",
  "decision": "ALLOW",
  "risk_score": 0.05,
  "scores": { "bot": 0.05, "ato": 0.02 },
  "signals": []
}

Challenge:

{
  "request_id": "f77b2abd-c5d7-44f0-be4f-174b04876583",
  "decision": "CHALLENGE",
  "risk_score": 0.65,
  "scores": { "bot": 0.65 },
  "signals": ["SuspiciousFingerprint"],
  "challenge": { "type": "CAPTCHA", "token": "..." }
}

Invalid serverKey:

{
  "decision": "ALLOW",
  "error": { "message": "[BotBye] Bad Request: Invalid Server Key" }
}

Middleware usage

Nitro server middleware (server/middleware/) runs before every matched request and is the best place to apply edge-level bot protection globally:

// server/middleware/botbye.js
import { evaluate } from "@botbye/nuxt/server";

export default defineEventHandler(async (event) => {
  const result = await evaluate({
    type: "validate",
    request: {
      request: event,
      // "x-botbye-token" is an example — pass the token from wherever you store it
      token: getRequestHeader(event, "x-botbye-token"),
    },
  });

  if (result.decision === "BLOCK") {
    throw createError({ statusCode: 403, message: "Forbidden" });
  }
});

Advanced: multiple instances

Use factory to create independent SDK instances (useful when protecting multiple projects from one service):

import { factory } from "@botbye/nuxt/server";

const sdk = factory();

sdk.init({
  // Use your project server-key
  serverKey: "00000000-0000-0000-0000-000000000000",
});

const result = await sdk.evaluate({
  type: "validate",
  request: { request: event, token },
});

Dev utilities

import { dev } from "@botbye/nuxt/server";

dev.setLoggerLevel("debug"); // "error" | "warn" | "info" | "debug" | "log"

Anti-Phishing

BotBye's anti-phishing detects look-alike sites that clone your pages to steal credentials. This integration serves the detection catcher from your own origin, so the BotBye domain stays hidden from the client.

• Anti-Phishing Protection overview
• Why a server-side integration is needed

Anti-phishing is identified by its own clientKey (available in your Phishing Project in the Dashboard), not the server key used by evaluate, so it is configured separately.

Init

Call phishing.init once at server startup — the same Nitro plugin used for init works well:

// server/plugins/botbye.ts
import { phishing } from "@botbye/nuxt/server";

export default defineNitroPlugin(() => {
  phishing.init({
    // clientKey from your Phishing Project on the Admin Dashboard
    clientKey: "00000000-0000-0000-0000-000000000000",
  });
});

Configuration

| Option | Type | Required | Description | |---|---|---|---| | clientKey | string | Yes | clientKey from your Phishing Project on the Admin Dashboard | | url | string | No | Override BotBye API endpoint (default: https://verify.botbye.com) | | logger.level | "error" \| "warn" \| "info" \| "debug" \| "log" | No | Log level (default: "info") | | logger.logger | TLogger | No | Custom logger instance implementing { error, warn, info, debug, log } | | timeouts.fetchCatcher | number | No | Timeout in milliseconds for each fetchCatcher call |

Usage

Anti-phishing needs two routes on your own origin, each proxied through fetchCatcher. Define them as Nitro server routes:

• SVG route — serves the SVG catcher. This is the URL your client passes to getCatcher({ url }).
• PNG route — serves the PNG that the SVG references (via innerPngUrl).

The paths are arbitrary — name the routes however you like. Pass the H3Event as request and the format. For the SVG, innerPngUrl must be the absolute URL of your PNG route — the browser loads that PNG directly from your origin.

// server/routes/botbye-catcher.svg.get.ts
import { phishing } from "@botbye/nuxt/server";

// Absolute URL of your PNG endpoint — the SVG catcher references it through innerPngUrl.
const PNG_CATCHER_URL = "https://your-site.example/botbye-catcher.png";

export default defineEventHandler(async (event) => {
  const catcher = await phishing.fetchCatcher({
    request: event,
    format: "svg",
    innerPngUrl: PNG_CATCHER_URL, // absolute URL of the PNG endpoint below
  });

  setResponseStatus(event, catcher.status);
  setResponseHeaders(event, catcher.headers);

  return catcher.body;
});

// server/routes/botbye-catcher.png.get.ts
import { phishing } from "@botbye/nuxt/server";

export default defineEventHandler(async (event) => {
  const catcher = await phishing.fetchCatcher({ request: event, format: "png" });

  setResponseStatus(event, catcher.status);
  setResponseHeaders(event, catcher.headers);

  return catcher.body;
});

We recommend embedding the SVG catcher: it is designed to keep tracking even when a phishing site copies all of your assets to its own infrastructure (the PNG route exists because the SVG catcher relies on it).

Multiple instances

phishing is a ready default instance. Use phishingFactory() to create isolated instances for multiple projects.

import { phishingFactory } from "@botbye/nuxt/server";

const phishing = phishingFactory();
phishing.init({ clientKey: "00000000-0000-0000-0000-000000000000" });

Documentation

• Web: https://botbye.com/docs/server-side/node-js/nuxt
• Markdown (for AI tools and agents): https://botbye.com/docs/server-side/node-js/nuxt.md