tavily-key-generator: signup automation and key validation for Tavily, Firecrawl and Exa

The problem: keys that look real but are not

Anyone wiring an LLM agent to a search backend eventually hits the same wall. Signing up for Firecrawl or Exa by hand is a browser task, not an API task, and it involves a CAPTCHA, an emailed one-time code, and a verification link. Doing that once is tedious. Doing it repeatedly to keep a pool of keys alive is not something a person should be doing at all. The second problem arrives right after the first: a freshly issued key can be malformed, rate-limited from the start, or already dead, and you only find out when a production query fails. This repository addresses both. Its stated scope is narrow and it says so explicitly: register Firecrawl and Exa keys, verify that each key genuinely works, and optionally hand the working keys to a unified search layer. It is not the product repository for MySearch, and the README points readers who want a public console, MCP server or Codex/Claude Code integration at MySearch-Proxy instead. The audience is therefore narrow: operators running a private key pool, not end users looking for a search front end.

Browser automation, a Turnstile solver and an email API in one loop

The registration path is a real browser session, not an HTTP client replaying a signup form. The README describes local real-browser registration paired with a local Turnstile solver, which is what lets the flow survive Cloudflare's challenge without a human. Behind the browser sits an email chain: the tool talks to either the Cloudflare Mail API or DuckMail to receive the verification code or the verification link, then feeds it back into the page. Once a key is extracted it is immediately exercised against the official service endpoint, so a key is only recorded if a live call succeeds. That ordering matters. Validation is not a separate scheduled job you have to remember to run; it is a gate on the write. The launcher presents three services (Tavily, Firecrawl, Exa), and the README notes that Exa results are persisted to exa_accounts.txt in the format email,EMAIL_OTP_ONLY,api_key. Uploading to a proxy pool is optional and only triggers when SERVER_URL and SERVER_ADMIN_PASSWORD are configured. The upload carries a service marker so the receiving server can route a Firecrawl key and an Exa key into different pools. The proxy/ directory in this repository now holds only a migration note; the runnable pool implementation lives elsewhere.

Getting it running: three commands and one .env

The Quick Start is short. Clone the repository, copy the environment template, edit it, then launch:

git clone https://github.com/skernelx/tavily-key-generator.git cd tavily-key-generator cp .env.example .env

On macOS or Linux the entry point is python3 run.py, or the wrapper ./start_auto.sh. On Windows it is start_auto.bat. The launcher then prints a numbered menu with 1. Tavily, 2. Firecrawl, 3. Exa. The README states that environment preparation is automatic: the tool checks for a venv, dependencies and a browser before starting, and the browser runs headless by default with a foreground mode available for debugging. The only configuration keys named in the material are SERVER_URL and SERVER_ADMIN_PASSWORD, both required for the optional upload step; without them, registration and validation still run and Exa results land in exa_accounts.txt. Email configuration is described as going into .env but the specific variable names are not listed in the README excerpt, so check .env.example rather than guessing. The launcher also lets you pick which domain to use for the current registration round, and the feature list mentions batch and concurrent execution.

Tavily is in the menu but not in service

The most important limitation is stated by the project itself. Tavily registration is unavailable: the README says the official site has closed its email registration entry point, based on the project's own local testing round, and that the Tavily option remains in the launcher only as a leftover. So the repository's name is now a historical artifact. If Tavily keys are the reason you arrived, this tool will not produce them, and no configuration change will fix that, because the failure is upstream on Tavily's side. A second limitation is structural: the whole approach depends on a browser session defeating a Turnstile challenge. That is a moving target. Signup pages change, challenge difficulty changes, and a solver that works today can stop working without a single commit to this repository. The README does not describe a fallback path or a headful manual-assist mode beyond switching the browser to the foreground for troubleshooting. Third, the project has no releases and no stated licence, which is a real consideration if you intend to run it inside a company.

How this differs from scripted HTTP signup and from hosted key brokers

The obvious alternative is a plain requests-based signup script: post the form, poll an inbox, parse the key. That is far simpler and has no browser dependency, which is exactly why it fails here. A Turnstile-protected form will not accept a scripted POST, so the HTTP-only approach either needs a paid CAPTCHA-solving service or breaks outright. This project trades that simplicity for a headless browser plus a local solver, keeping the whole loop on your machine. The other alternative is a hosted key broker that sells or provisions API access for you. That removes the automation work entirely but changes the trust model: your keys, and the traffic behind them, pass through someone else's infrastructure, and you inherit their pricing and their uptime. Running this repository locally keeps credentials in your own .env and your own exa_accounts.txt. There is also the relationship to MySearch-Proxy to weigh. The README is explicit that this repository is the upstream key source and MySearch-Proxy is the console, MCP and gateway layer. If you want a search console, this is not it, and installing it expecting one will be a disappointment.

Maintenance cost and the licence question

There are no published releases, so every update arrives as a commit on main and there is no version to pin against or changelog to read before upgrading. The last push recorded is 2026-03-22. Because the tool drives a third-party signup page and a CAPTCHA challenge, the practical upgrade cadence is set by Firecrawl and Exa, not by the maintainer: when a signup page changes, you either pull a fix or patch the browser flow yourself. Budget for that rather than assuming a stable dependency. The licence field in the repository metadata is unknown, and the README does not state one. Without a licence file, the default position is that no rights are granted beyond what your jurisdiction's law allows, which is a problem for commercial or internal corporate use. Treat that as a blocker to resolve, not a formality. The README also notes that the proxy/ directory here holds only a migration note, so if you were expecting a self-contained pool server, the runnable piece lives in a separate project and you will need to account for that second deployment.

Editorial conclusion

Adopt it if you need a local, unattended source of Firecrawl or Exa keys and you already run the MySearch-Proxy pool that consumes them. Do not adopt it if you need Tavily keys, since the README states the site has closed email registration and the option is retained in the launcher but marked unavailable. Before committing, verify three things: that the repository actually carries a licence file, since none is stated; that your .env email provider (Cloudflare Mail API or DuckMail) can receive the OTP and verification link; and that the Turnstile solver still passes on the current signup page, because that is the component most likely to break without any code change on your side.

Official sources

1. Issues
2. README
3. skernelx/tavily-key-generator on GitHub