notebooklm-py: An Unofficial Python Client for NotebookLM's Undocumented API

The gap notebooklm-py fills between the NotebookLM UI and a script

NotebookLM is a grounded question-answering product: you load sources, Gemini reads them, and answers come back with citations. The web interface is built for reading, not for piping. If you want to import thirty PDFs, run the same question across a set of notebooks, or pull every generated artifact onto disk, the UI makes you click. notebooklm-py targets that gap. Its README describes "full programmatic access to NotebookLM's features, including capabilities the web UI doesn't expose," and lists batch downloads, quiz and flashcard export in multiple formats, and mind map JSON extraction as examples of the extra surface. The audience is narrow and technical: Python developers, and more specifically people wiring NotebookLM into an agent loop. The README frames the intended pattern as using NotebookLM as a "zero-token synthesis + memory layer an agent drives in a loop," where the agent orchestrates (create a notebook, add sources, ask a question) and the expensive reading happens server-side. That framing tells you who this is for. It is for someone who already has a NotebookLM account, already trusts the product's answers enough to build on them, and wants to stop being the person who clicks.

How it talks to NotebookLM: undocumented endpoints behind a Python surface

The README is explicit that the library calls "undocumented Google APIs." There is no public NotebookLM API contract here; the client drives the same underlying service the web product uses. That single design decision explains most of the project's behaviour and most of its risk. On top of that transport sit three interfaces: a Python API, a CLI, and an agent skill. The skill side is not an afterthought. The repository ships a root SKILL.md for GitHub and `npx skills add` discovery, a `notebooklm skill install` command that places skills into Claude Code and `.agents` skill directories, and repo-level Codex guidance in AGENTS.md. There is also an MCP server documented separately in docs/mcp-guide.md, which the README suggests as a way to expose a notebook of internal docs so a coding agent answers from your material with citations. The data flow in the recipes is consistent: sources go in (URLs, PDFs, YouTube, Google Drive), NotebookLM does the reading and citation, and artifacts come out (MP3, MP4, PDF, PNG, CSV, JSON, Markdown), with export to Google Docs and Sheets. One naming detail matters for anyone reading older material: the README notes that in July 2026 Google rebranded NotebookLM to Gemini Notebook, that links redirect, and that the library "drives the same underlying service and works unchanged." The package name stayed notebooklm-py.

Installing and running it: the commands the README actually gives

The README does not print a full quickstart in the excerpt available, so the concrete commands it does name are worth separating from the ones it only gestures at. Installation is via PyPI, and the badge line lists supported interpreters as Python 3.10 through 3.14. The CLI surface named in the material includes `notebooklm skill install` for placing the skill into Claude Code and `.agents` directories, and `source add-research "your topic" --mode deep` for Deep Research, which the README links to docs/cli-reference.md. The README also references `note create` and `ask --save-as-note` for writing session notes into a notebook, and `ask --json` for structured, source-grounded answers. The skill is also discoverable through `npx skills add`. What the README does not spell out is authentication: the excerpt never shows a login command or an environment variable holding credentials or a session token. That is the first thing to check in the repository itself, because an unofficial client that drives a logged-in Google service has to establish a session somehow, and the mechanism determines how brittle your automation is. Treat the command list above as the verified subset, not the whole CLI.

Where notebooklm-py breaks, and when it is simply the wrong tool

The project's own warning block is unusually direct, and it should be read as a specification of failure modes rather than legal boilerplate. Three are named: the library is not affiliated with Google, the APIs may break because Google can change internal endpoints anytime, and rate limits apply, with heavy usage possibly throttled. The README's own recommendation is that it is "best for prototypes, research, and personal projects." Take that seriously. A breaking endpoint change is not a bug you can patch around locally; it is a change in a service you do not control, and the fix depends on someone reverse-engineering the new call. Rate limiting is the second constraint: any pipeline that loops over many notebooks or bulk-imports large source sets is competing with whatever throttling Google applies to the account, and the README gives no numbers. The third limitation is category-level. If your requirement is a supported integration with an SLA, an audit trail, or a data-processing agreement, this is the wrong tool regardless of how well it works today, because the contract underneath it does not exist. The same applies if your organization's policy forbids sending source material to a consumer Google account. None of this is a defect in the library. It is the shape of the problem it chose to solve.

What to compare it against before you commit

The honest alternative is not another unofficial NotebookLM client. It is building the retrieval layer yourself: a vector database plus an embedding pipeline, with your documents chunked, embedded, and queried by an agent. The README itself draws this comparison, calling the notebook-over-MCP approach "a zero-infra alternative to standing up your own vector DB and embedding pipeline." The difference in approach is real and worth stating plainly. A self-hosted vector store gives you control over chunking, embedding model, index, and retention, and it does not depend on a third party's internal endpoints. What it does not give you is Gemini doing the reading, the citation behaviour of a grounded notebook, or the generated artifacts (audio overviews, videos, slide decks, quizzes, flashcards, infographics, data tables, mind maps, study guides) that NotebookLM produces as a side effect of the same sources. If your workload is mostly question answering over your own documents, the vector store is the more durable choice and the README does not pretend otherwise. If your workload is turning a document set into podcasts, study material, or structured exports, there is no self-hosted substitute for the generation step, and that is the case where notebooklm-py earns its place.

Maintenance cost, API drift, and what the MIT licence does not cover

The release cadence visible in the material is roughly one release per month through mid-2026, with v0.8.0 in early August, v0.8.1 two weeks later, and v0.8.2 in early September. That rhythm is consistent with a project tracking a moving target: frequent small releases are what endpoint drift looks like from the outside. Budget for that. An automation built on notebooklm-py needs someone watching releases, because a silent endpoint change will surface as a failed call in your pipeline, not as a deprecation notice. The licence is MIT, which governs the code in this repository. It does not govern the Google service the code calls. Nothing in the MIT grant gives you rights to NotebookLM, to the undocumented endpoints, or to the content you load into a notebook, and the README's own disclaimer that the project is not affiliated with Google is the relevant statement here. If your use involves other people's data or regulated material, the terms you need to satisfy are Google's, not this repository's. That is a question for your own counsel, not something a licence file answers.

Who should adopt notebooklm-py, and what to verify on day one

The fit is a developer automating their own NotebookLM account: bulk source import, repeated questions across notebooks, batch artifact download, or an agent that consults a notebook before writing code. The agent-skill path is the most distinctive part of the project, and the recipes in the README (a "Master Brain" notebook appended to each session, a notebook of internal RFCs exposed over MCP) describe a workflow that a vector store would require real infrastructure to match. The misfit is anyone who needs a supported contract. If your pipeline feeds a customer-facing product, or if a broken endpoint on a Tuesday would page someone, this library is not the foundation. Three things to verify before you build on it. First, authentication: find the login or credential mechanism in the repository, since the README excerpt does not show it, and confirm it works against the current service. Second, rate limits: run your intended request volume against a test account before designing around it, because the README gives no thresholds. Third, artifact coverage: confirm that the specific outputs you need (MP3, MP4, PDF, PNG, CSV, JSON, Markdown, or the Docs and Sheets exports) are produced for your account, since the README lists them as capabilities rather than guarantees. If all three hold, the library does something no supported Google API currently does.

Editorial conclusion

Adopt notebooklm-py if you are automating your own NotebookLM account for research pipelines, batch artifact export, or agent-side grounded recall, and you accept that Google can break the endpoints at any time. Do not adopt it for customer-facing or compliance-bound workloads, and do not treat the MIT licence as covering the Google service you call through it. Before committing, verify that login still succeeds against the current endpoints, that your account's rate limits tolerate your planned request volume, and that the artifact formats you need are actually produced by your account.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. teng-lin/notebooklm-py on GitHub