# google-apis-rs: generated Rust bindings for the Google APIs

> The Byron/google-apis-rs repository holds mako scripts that generate one Rust crate per Google API from the Google discovery service, along with CLI programs for the same services. It is in maintenance mode, with the project pointing at the alternative google-apis-rs implementation under the google-apis-rs organisation, so it suits code that already depends on these crates.

**Byron/google-apis-rs** — A binding and CLI generator for all Google APIs

- Repository: https://github.com/Byron/google-apis-rs
- Website: http://byron.github.io/google-apis-rs
- Stars: 1,136 · Forks: 154
- Language: Rust
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/byron-google-apis-rs

## A code generator, not a handwritten client

The repository holds mako scripts that generate all Google APIs as described by the Google discovery service, and the generated source for each API sits in the `gen` subdirectory. Each Google API becomes its own crate that can be used like any other crate. The consequence is that you are not reading handwritten bindings, you are reading output from a generator, and the quality of the result is bounded by the templates in `src/generator` and the schema files under `etc/`. The public features the project claims are an idiomatic Rust implementation, first-class documentation with cross-links and complete code examples, support for all features including downloads and resumable uploads, and built-in safety and resilience, with the concrete example being the ability to trigger retries for all operations that may temporarily fail because of a network outage. The homepage is a documentation index, and the recommendation for finding a library of interest is to go through the API documentation index rather than browsing the repository.

## Maintenance mode, and the successor the project points at

The status banner at the top of the documentation is unambiguous. No new features will be implemented, but contributions are welcome, and from time to time new releases will be published to crates.io. The crates are considered done and only minimal time will be invested to keep them relevant, and the listed commitments are specific: reply to issues and triage them, provide support for pull requests, occasional updates of all crates to update them with the latest API definitions, probably no more than twice a year, and dependency updates to avoid security issues. The last push was on 2026-10-17, and the published releases are google-clis-common v7.0.0 and google-apis-common v7.0.0, both on 2024-10-15, with google-apis-common v6.0.4 on 2024-05-29. The documentation then points at an alternative implementation of these crates, hosted under the google-apis-rs organisation, and says it may be better suited for you. That is the single most actionable line in the whole file for anyone starting fresh.

## Prerequisites that pin the Python version exactly

Generating the APIs yourself needs a specific toolchain, and one requirement is unusual enough to break a build. The prerequisites are make, python, an internet connection with wget, and Rust stable. The Python constraint is stated with a reason: you need Python 3.8, because 3.9 and later introduced breaking changes that break the dependencies. The mako template engine is a Python program, so Python has to be on the system, and other programs the build calls depend on it as well. The Makefile resolves this by creating a virtual environment directory named from the platform, `.pyenv-$(shell uname)`, with a pinned `VENV_VERSION = 20.24.3` and a `VENV_BIN = .virtualenv.marker` sentinel, and by activating it for every Python invocation. Make downloads the remaining prerequisites into hidden directories inside the repository, which is why wget and a network connection are on the list. The Rust requirement is stated as stable 1.6 or greater, with rustup suggested for per-project toolchain control.

## A self-documenting makefile is the entry point

The Makefile is written to describe itself, so calling `make` with no target prints the list of valid targets rather than doing something surprising. The list includes `help-api` and `help-cli` to show the per-API and per-CLI build targets, `docs-all` to run cargo-doc across all APIs and assemble the index, `docs-all-clean` to remove the generated documentation, `github-pages` to invoke ghp-import, `regen-apis` to clear and regenerate all generated APIs, `license` to regenerate the main licence file, and `update-json` to rediscover the API schema JSON files and update api-list.yaml with the latest versions. Building an individual API's documentation is `make <api-name>-doc`, running doctests across all APIs is `make cargo-api ARGS=test`, and the same for a single API with `make <api-name>-cargo ARGS=test`. The command line programs follow the same convention, using `-cli` in place of `-api`, with `help-cli` listing them individually. A first pass through the targets looks like this:

```bash
make help-api
make docs-all
make cargo-api ARGS=test
```

The first command lists what can be built, the second assembles the documentation index, and the third runs the doctests across every generated API.

## Parallel make is a trap on the first run

The documentation warns about a specific failure that catches people out. In theory you can run make with `-j4` to process four jobs in parallel, but cargo may be run for some of those jobs and do a full build, which can fail because it will be updating its index, and the index is a shared resource that does not work for multiple cargo processes at once. The workaround is a two-phase workflow. The first time, when you run `make docs` and `make cargo ARGS=test`, you should not run things in parallel. The second time, once all dependencies for all APIs have been built once, you can parallelize at will because cargo will not update its index again. For the schema refresh itself the same pattern appears, with a documented command that deletes the dependency files and refetches, using `-j8` to allow eight parallel schema downloads. The dependency files act as a cache of the discovered API list, and the documented way to force a full update is to delete them and run make again. The refresh command is:

```bash
rm -f .api.deps .cli.deps && FETCH_APIS=1 make update-json -j8
```

After the schemas are in place, the check that decides whether an API is usable is a cargo check across the generated crates:

```bash
make cargo-api ARGS=check
```

## Adding an API that fails the check

The update workflow has a defined shape for the case where a newly discovered API does not compile. After refreshing the schemas you run `make cargo-api ARGS=check`, and each time that check fails you add the API to the list of forbidden APIs with a note explaining why it fails, then regenerate all APIs with the same invocation, and when every API passes `cargo check` you commit the changes in the `shared.yml` file. The forbidden list lives in the repository at `etc/api/shared.yaml`. The list of APIs to generate is based on a query of the Google discovery API and is then baked into a make-compatible dependency file, which is the cache mentioned above. Version numbers for the two program types are set in `etc/api/type-*.yaml`, where the wildcard resolves to the supported program types, `cli` and `api`, and the key to edit is `cargo.build_version` at the time of writing.

## Three CLI crates published by someone else

There is a warning in the documentation that deserves to be read before you depend on anything from this project. Three crates are not under the project's control and were published by another party: `google-privateca1-cli`, `google-recaptchaenterprise1-cli` and `google-resourcesettings1-cli`, and the instruction is to use them at your own risk. This is a supply-chain detail rather than a technical one, and it exists because the CLI generation pipeline publishes crates with predictable names, so a name collision is possible. The repository layout is consistent with a monorepo that separates the shared runtime crates from the generated output: `google-apis-common/` and `google-clis-common/` are workspace members along with `src/rust/preproc`, `gen/` is explicitly excluded from the workspace, and the root Cargo.toml uses resolver 2. The root holds LICENSE-APACHE, LICENSE-MIT and a combined LICENSE.md, while the licence itself is a custom one, and the requirements file shows the Python side of the toolchain, with mako, inflect, pyyaml, pytest, pyright, mkdocs, ghp-import, pre-commit and urllib3 among the pinned or listed entries.

## Conclusion

Adopt Byron/google-apis-rs if you already depend on its crates or need its CLI programs, since regenerating against current API definitions is part of what the project still does. For a new integration, look at the alternative implementation the project itself recommends, google-apis-rs under the google-apis-rs organisation, which may be better suited. Before choosing either, check the three CLI crates published by another party, google-privateca1-cli, google-recaptchaenterprise1-cli and google-resourcesettings1-cli, which are marked as outside the project's control, and note that the root holds LICENSE-APACHE, LICENSE-MIT and a combined LICENSE.md, under a custom licence.

## FAQ

### Is Byron/google-apis-rs still actively developed?

No. The project is in maintenance mode: no new features will be implemented, contributions are welcome, and new releases will be published to crates.io from time to time. The documentation points to an alternative implementation under the google-apis-rs organisation that may be better suited.

### What Python version is needed to generate the Google API crates?

Python 3.8, because 3.9 and later introduced breaking changes that break the dependencies. The Makefile sets up a virtual environment pinned to version 20.24.3.

### How do I build the documentation and run the doctests?

Use `make docs-all` to build the documentation index, `make <api-name>-doc` for an individual API, `make cargo-api ARGS=test` to run doctests across all APIs, and `make help-api` to list the available API targets.

### Can I run make in parallel?

Not on the first run. Cargo may update its shared index, which does not work for multiple cargo processes at once. Once all dependencies have been built once, you can parallelize at will.

### Which crates from this project are published by another party?

google-privateca1-cli, google-recaptchaenterprise1-cli and google-resourcesettings1-cli are not under the project's control and were published by another party, and the documentation says to use them at your own risk.

## Sources

- [Byron/google-apis-rs on GitHub](https://github.com/Byron/google-apis-rs)
- [Issues](https://github.com/Byron/google-apis-rs/issues)
- [Project website](http://byron.github.io/google-apis-rs)
- [README](https://github.com/Byron/google-apis-rs/blob/main/README.md)
- [Releases](https://github.com/Byron/google-apis-rs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/byron-google-apis-rs