Google's Elixir API Clients Are Archived: What That Means for Your Project

You're building an Elixir app and need to talk to Google Cloud Storage, Drive, or maybe the YouTube API. You could write your own HTTP client and wrestle with Google's discovery documents, or you could reach for a generated client library that already knows the API surface. For years, that second option existed in the form of elixir-google-api—a repository of auto-generated Elixir clients for Google's APIs. It's now archived and unmaintained, but it's still worth understanding what it offered and whether it fits your situation.

What It Does

The repository contains client libraries for interacting with Google APIs, all generated from Google's API definitions. Each client lives under a clients/ directory with its own README, and the main folder holds the code that generates them. The project is written in Elixir and provides modules you can call directly from your application—for example, GoogleApi.Storage.V1.Api.Buckets.storage_buckets_list/2 to list buckets or GoogleApi.Drive.V3.Api.Files.drive_files_list/1 to list files.

Authentication is handled separately through the goth package (also required as a dependency). The generated clients themselves are described in the README as "under development and should be considered experimental"—a caveat that now carries more weight given the deprecation notice.

Why It's Cool

Even in its archived state, there are a few things about this project that made it useful, and still might for certain use cases.

• It solved the boilerplate problem. Google APIs have large, complex surfaces. Manually writing Elixir modules for every endpoint, request shape, and response type would be tedious and error-prone. Generating clients from the official discovery documents meant you got full API coverage without hand-coding each method.

• Authentication was cleanly separated. Rather than baking auth into every generated client, the project leaned on goth for token handling. That's a sensible separation of concerns—your auth strategy (service accounts, Application Default Credentials, OAuth 2.0) stays independent from the API calls themselves.

• The mix task for OAuth testing was genuinely handy. The mix google_apis.auth task let you fetch a token for a specific scope by opening a browser link, pasting back a verification code, and getting your token printed to the console. For quick testing against APIs like Drive or Gmail, that's a nice convenience.

• Service account setup followed standard patterns. Setting GOOGLE_APPLICATION_CREDENTIALS to point at a service account key file is the same approach used across Google's official libraries, so the mental model transfers.

• The generation pipeline was open. Four mix tasks (google_apis.discover, and others) componentized the build process, meaning you could regenerate clients if needed rather than depending solely on pre-built hex packages.

How to Try It

The README is upfront: this is archived and unmaintained. But if you want to experiment or you're maintaining an existing project that already depends on these clients, here's how it worked.

First, add a client and goth to your mix.exs:

defp deps do
  [
    {:google_api_storage, "~> 0.19.0"},
    {:goth, "~> 1.2.0"}
  ]
end

Then run:

$ mix deps.get

For authentication, set up Application Default Credentials by creating a service account key file and pointing the environment variable at it:

export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service_account.json

If you're deploying to App Engine, Compute Engine, or Container Engine, credentials are available by default.

Once you have a token (via goth or the OAuth mix task), you can make a request:

{:ok, token} = Goth.Token.for_scope("https://www.googleapis.com/auth/cloud-platform")
conn = GoogleApi.Storage.V1.Connection.new(token.token)

{:ok, response} = GoogleApi.Storage.V1.Api.Buckets.storage_buckets_list(conn, project_id)

Enum.each(response.items, &IO.puts(&1.id))

The repository is at github.com/googleapis/elixir-google-api. The README also points to an elixir-samples repository for more examples and a getting started tutorial.

Final Thoughts

The honest assessment here is straightforward: this project is archived, and the README says so plainly. It's not receiving updates, and the clients come "as-is" without support or guarantees. If you're starting something new today, you'd want to look at actively maintained alternatives or consider generating your own clients. But if you're maintaining an existing Elixir project that already uses these libraries—or you're curious about how generated API clients work in practice—the code and the generation pipeline are still there to read and learn from. Sometimes an archived project is still a useful reference, even if it's not a dependency you'd add fresh.

Follow @githubprojects for more developer tools and open source projects.