gemini-web-to-api declares a module path Go cannot fetch, and documents two sets of defaults

A module path Go will not let anyone fetch

The module declaration is the first line of the dependency file and it reads `gemini-web-to-api`, with no host prefix at all. Go requires a module path's first element to contain a dot before a module can be resolved remotely, since a bare name is reserved for the standard library, so this project cannot be imported with `go get` by anything outside its own tree. That is consistent with how it is meant to be used, as a server you clone and run rather than a library you depend on, but it also means there is no way to vendor it, depend on it from another Go module, or pull a tagged version of it into a build. Everything else about the dependency list is conventional and modern: a third major version of the Fiber web framework, an HTTP client library, a dotenv loader, dependency injection and structured logging from one vendor, and a UUID helper. The interesting part is in the indirect list.

The indirect dependencies describe a browser impersonation layer

Among the indirect requirements sit a TLS library built for impersonation, a QUIC and HTTP/3 stack, a compression library, brotli, a message-pack encoder, a fast HTTP implementation and standard crypto and network packages. That combination is what a client that intends to look like a browser needs: the TLS and QUIC pieces control the handshake fingerprint and the protocol version, the compression pieces handle the encodings a real browser sends, and the fast HTTP layer keeps the connection hot. None of that is what a server-to-API client needs, and none of it appears in the README. It is the clearest evidence in the repository that the Gemini web endpoint applies anti-automation measures and that this project works around them, which is also why the documentation's own warnings about terms of service and account actions are not boilerplate. A TLS fingerprint that does not match the browser will fail regardless of how valid the cookie is.

Three defaults in the documentation contradict the shipped example

The documentation and the example environment file disagree three times, and the gaps are not cosmetic. The cookie rotation interval is documented with a default of thirty minutes and set to fourteen hundred and forty in the example file, a forty-eight-fold difference in how often the server cycles the session credential. The rate limit is documented as ten requests per minute and set to thirty in the example. The deployment mode is documented as production in the container run example and set to development in the example file. A fourth, smaller inconsistency sits in the volume paths: the container run example mounts a cookies directory from the host while the Compose file mounts a dot-prefixed one, so a reader following the two paths ends up with credentials in two different places or with an empty mount. When you copy the example file you get the example's values, and when you follow the table you get the documented ones.

The quick start asks for an older Go than the module needs

Cloning and building is the documented path into all of this:

git clone https://github.com/ntthanh2603/gemini-web-to-api.git
cd gemini-web-to-api

The run-methods table offers three ways to start the server and lists a Go requirement for the direct path. That requirement is four minor versions below what the dependency file declares, and the container build uses a matching Alpine image on the newer line. In practice the two lines the table sends you to run are the ones that will fail first on an older toolchain, because the module's own version directive is what the build enforces, and the toolchain line in the build file is newer still than the requirement in the quick start. The Compose path avoids the problem entirely, and the Task-based path needs a separate runner installed, so of the three documented options the one with a written-down version floor is the least reliable. This is the kind of drift that appears when a project documents for its users while upgrading its own build, and it costs a newcomer a confusing error rather than a clear one.

The credential is an account, not a scoped key

Authentication is a complete cookie header taken from a signed-in browser session, passed in through an environment variable, alongside an optional variable naming the account slot when the web interface exposes one, with the documented requirement that both come from the same browser tab. The project's own warnings say the values provide direct access to the account and should never be shared or committed, and they appear twice, once per installation path. The container definitions take that seriously in a way many projects do not: a non-root user runs the process, the cache and temporary directories are tmpfs mounts with size caps so nothing persists in the image layer, and the cookie directory is a bind mount rather than something baked in. What no amount of container hygiene changes is the nature of the credential. A leaked API key is a billing problem with a scope; a leaked session cookie is an authenticated browser session.

Three protocol surfaces and a model label from the web tier

One server exposes three shapes of endpoint, OpenAI, Claude and Gemini compatible, on port 4981, and the documentation claims drop-in compatibility with existing SDKs for all three. There is an OpenAI-compatible chat completions route, text-to-image generation returning authenticated base64 image data, image inputs by remote URL or data URL with multiple reference images, an interactive documentation surface, a health endpoint and a Compose service definition with a health check. The test request uses the model identifier `gemini-advanced`, which is a label from the consumer web interface rather than an API model name, and that is the clearest sign of what the server really is: a translator from web labels to API shapes. Four example clients ship in Python for the OpenAI, Anthropic, Gemini and deep-search paths, so the drop-in claim is at least demonstrated rather than asserted, even though the label space behind it is the web tier's.

Production ready and research only, on the same page

The feature list calls the project production ready and cites Compose support, a documentation UI and health checks, while the notice at the top says it is for research and educational purposes only and asks readers to refrain from commercial use. Both statements are in the same document, a few hundred lines apart. Read strictly, the second one governs: the deliverable is a local server for testing an integration, and the production language describes the deployment ergonomics rather than an endorsement. The repository structure backs the narrower reading, with a test directory, a documentation folder, an assets folder, continuous integration configuration and three tagged releases inside two weeks in late summer 2026, which is the cadence of a project being maintained seriously even if it is being maintained for a purpose its own author disclaims commercially. That combination is worth weighing before you point anything at it.

Editorial conclusion

Read this as a technically competent reverse engineering project with a Terms of Service problem attached, and decide the second question before the first. The repository is explicit that it is not affiliated with Google, that using reverse-engineered cookies may not comply with Google's terms, and that the author accepts no responsibility for account actions or data loss. Because authentication is a live browser session cookie, a mistake or a leak reaches the account itself rather than a scoped API key, so treat the credential as the account. If you evaluate the engineering regardless, three things are worth checking first. The module path contains no domain, so the package cannot be imported by other Go code. The quick start asks for a Go version four minors below what the module requires. And the shipped example environment disagrees with the documented defaults on the cookie rotation interval, the rate limit and the deployment mode.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. ntthanh2603/gemini-web-to-api on GitHub
4. README
5. Releases