NotebookLM SDK

1What it does

An unofficial Python SDK that wraps NotebookLM's consumer surface in a programmable API. The object model mirrors the product: create and manage notebooks, upload sources (URLs, text, files), chat with the source corpus, and trigger artifact generation — the audio overview, study guides, and other built-in outputs — then poll for and download results. It turns NotebookLM into a library call instead of a browser tab, which is the missing piece for anyone building tools on top of NotebookLM rather than inside it. The SDK handles the session/auth layer that raw scripting tools leave as an exercise, making it the base layer most NotebookLM automation projects end up building on — or should have built on instead of rolling their own.

2When to use it

Reach for it when you're building something — a CLI that converts a reading list into audio, a bot that answers from a curated notebook, a pipeline that syncs sources and regenerates artifacts on a schedule. An SDK is the right abstraction when you need more than one scripted action; for a single "generate one podcast" job the single-purpose automator is less machinery. Skip it for anything enterprise — the official NotebookLM Enterprise API is the supported programmatic path, with auth, quotas and a contract; this SDK is for the consumer-account gap where the official API doesn't reach.

3How to get started

pip install per the README, then authenticate — consumer NotebookLM tooling authenticates via your Google session, so the setup is a cookie/token export the README documents rather than an OAuth flow. The first script is usually client = NotebookLM () → list notebooks → pick one → client.chat(...) against its sources — verify the auth chain before automating artifacts. Source upload (a URL or file path) is the second thing to test; artifact generation (audio overview) is the third, and it's the longest-running call — the SDK exposes polling helpers for the async generation jobs.

4Configuration

Configuration is the session material — where the credential blob lives, how it's refreshed, which Google account it represents. Keep it out of the repo (env var or a gitignored file) and treat it like a session cookie, because it is one. The SDK inherits the fragility of the surface it wraps: a NotebookLM backend change can shift an endpoint and break a method until the SDK catches up — pin a version, and re-test your calls after upgrading. Rate your own usage: an unattended loop hammering a consumer surface is how accounts get flagged; deliberate pacing is part of the configuration.

5Things to know

• Unofficial — built on reverse-engineered endpoints; breakage is a when, not an if, and the fix latency is maintainer- dependent.
• It's a foundation, not an app — you still write the pipeline; the SDK just removes the protocol plumbing.
• Session-based auth = session-based risk — use a dedicated account for automation, not your primary Google identity.
• The official Enterprise API is the same idea with a contract — if your use can move to it (Workspace/enterprise account), it should; the SDK's niche is everything that can't.
• The SDK's chat calls return the same citation structure the web UI shows — parsed source references, not raw text — which makes programmatic verification workflows possible.
• Notebooks created via SDK appear in the web UI immediately — the two surfaces share state, so a script can prep sources and a human can review in the browser; that hybrid loop is where the SDK earns its keep.
• Method coverage tracks what the author needed — check the README's API list against your pipeline's calls before committing to it as a base layer.
• Error modes are the honest part — session expiry and endpoint drift surface as exceptions, so wrap calls in retry-and-alert logic rather than assuming a long-running pipeline stays healthy on its own.

6Related on the map

References

• Repository
• NotebookLM Enterprise API docs