Event Scanner: What Gets Sent and What Is Kept

npx @databuddy/scan (or bunx @databuddy/scan) finds user actions in your repository that have no analytics event. It reads your code locally and sends the relevant parts to a model that classifies each action. This page lists every piece of data involved so you can decide whether to run it.

Check before you send

  • npx @databuddy/scan --dry-run lists every file and line range that would be sent, and sends nothing.
  • npx @databuddy/scan --dry-run --json prints every code segment and the tracking catalog that would be sent. Real requests carry the same data split into batches of up to four segments; with your own gateway key they also include the scanner's fixed classification instructions.
  • npx @databuddy/scan <folder> sends code only from that folder. It still reads the rest of the repository locally, with the same exclusions, to find existing tracking, and sends that as a list of event names and file:line references so actions tracked elsewhere are not reported as missing. It also reads the repository root's .env, only to look for AI_GATEWAY_API_KEY.

Before sending anything, the CLI prints where the code is going and how many files it comes from.

What is sent

For JavaScript, TypeScript, Vue, Svelte, Astro and HTML, the scanner sends only the code around each user action it finds: the handler, the functions it calls, and the route it posts to. For Python it sends only decorated write routes (FastAPI, Flask or Django POST, PUT, PATCH and DELETE handlers), each as its own function; Python files without one are not sent. Swift files, and any file it cannot parse, are sent whole.

It never sends:

  • files that are not tracked by Git, including .env files;
  • tests, fixtures, examples, and e2e, Cypress or Playwright folders;
  • symlinks, and files that look like they contain private keys or live API tokens.

Secret detection is a safeguard, not a guarantee. Review --dry-run output for repositories with unusual credential formats.

Where it goes

By default, requests go to Databuddy's scan API at api.databuddy.cc. The API forwards them to the Jev model (typesafe-ai/jev) on Vercel AI Gateway with zero data retention required on every call, which limits routing to providers that do not retain prompts or outputs.

The API holds your code in memory only while it answers the request. It does not write source code to logs, databases, caches or error reports, and does not use it to train models. It returns only classification labels, never generated text.

What Databuddy records

Scan request logs contain these fields. Routine successful requests are sampled, so not every request is kept:

  • method, path, status, duration and request size;
  • the HTTP client's user agent, for example node;
  • a random run ID generated per scan and the CLI version;
  • the number of code segments, the model gateway's status and timing, input token count, and how many findings were missing or covered.

The first request of each run also records a scan_run_started event in Databuddy's own analytics, keyed by the random run ID, with the CLI version. This is how we count scans.

For rate limiting (600 requests a minute, 5,000 a day), your IP address is hashed with a server secret and used as a Redis key that expires with its window. The IP address itself is not logged or stored.

Nothing recorded contains source code, file paths, repository names, Git remotes or account details. Logs are processed by Axiom and Superlog.

Keep your code off Databuddy

Set AI_GATEWAY_API_KEY to your own Vercel AI Gateway key, in your shell or in the scanned repository's .env file. Requests then go directly from your machine to your Vercel account with the same zero data retention setting, and Databuddy receives nothing. The scanner reads only that one variable from .env.

What stays on your machine

Results are cached in ~/.cache/databuddy/scan (or $XDG_CACHE_HOME/databuddy/scan when XDG_CACHE_HOME is set), so unchanged code is not sent again. The cache holds the list of scanned files with their hashes, the tracking calls it found, the locations of the actions, and the model's classifications. Delete the folder to clear it.

The scanner never edits your repository. It is MIT licensed and its source is in the Databuddy repository.

How is this guide?