How I Used an Unofficial NotebookLM API to Batch-Create a Cinematic AI History Series

Google never shipped a public API for NotebookLM. The community shipped one anyway. I needed to use it to ship a whole video series — and I don’t write code.

This post is really about that second part. The interesting story isn’t the unofficial NotebookLM tool. The interesting story is that an apprentice-style AI — Claude Code — was able to take a public GitHub link, a few sentences from me describing what I wanted, and turn that into a working pipeline that produced a finished course. I was the director. Claude was the entire production crew.

Quick translation, in case the term “API” is new: an API is a way for one program to ask another program to do something, without a human clicking buttons in the middle. Most modern software has one tucked away under the hood. NotebookLM, on launch, did not — at least not one Google opened up to outsiders. So if I wanted to spin up a stack of notebooks at scale, I needed another route.

The series itself was a cinematic AI history walk — one episode per moment that shaped the field (Turing, AlexNet, Attention Is All You Need, AlphaGo’s Move 37, all the way through DeepSeek and Anthropic’s founding). Each video had its own curated stack of sources. Each one needed an Audio Overview and a Video Overview generated from those exact sources, and nothing else.

Doing that by hand in the NotebookLM web app is doable for one notebook. For a whole series, in the same week, with consistent style, it isn’t. Without an API, you’d be uploading sources, waiting, clicking, waiting again, for every single notebook.

The actual point: natural language as the director

Claude Code is an AI you run in your Terminal. The thing that makes it different from a chat window is that it can do things on your computer — read files, install software, run commands, drive a browser — on its own, after you describe a goal in plain English.

For this project, my entire technical contribution was three sentences and a link. Roughly:

“Here’s the GitHub link to a community NotebookLM CLI: github.com/<owner>/<repo>. I want you to use it to create one notebook per episode in a folder I’ll point you at, add the listed source URLs to each, then trigger a Video Overview for each notebook and download the result. For uploads and video generation that the CLI can’t do, fall back to driving the NotebookLM site in a real browser. Take screenshots of every step. Pause and ask before anything destructive.”

That’s it. No code, no glue, no scripting, no figuring out which Python version to install. Claude read the repo’s README, saw what the tool could and couldn’t do, set up a virtual environment, ran the boring commands, hit the walls, and reached for the right fallback — without my hands ever touching a keyboard for the technical pieces. My job was to describe the outcome and approve the destructive steps. The same way I’d brief an editor or a producer.

What Claude actually did, in plain language

Here’s the same workflow, broken down into what Claude did at each layer. None of these were steps I wrote out; they’re how Claude chose to organise the job once I gave it the goal.

1. Read the GitHub repo. Claude pulled the README and code from the public repo I linked, figured out what the unofficial CLI could do (list notebooks, create a notebook, add web URLs as sources, read contents), and noted where it stopped (no file uploads, no video generation).
2. Installed the tool in a sandbox. Created a Python virtual environment — a small isolated folder that keeps a tool’s pieces from interfering with anything else on the computer — and installed the CLI into it. The command ended up at .venv/bin/notebooklm, which is just a file path on the machine, the same way Documents/Reports/Q3.pdf is a path.
3. Ran the bulk setup through the CLI. For each episode, Claude ran notebooklm create to make a new notebook, then notebooklm add-source for each web URL in the episode’s research stack. Plain text commands going out, confirmations coming back. No browser involved.
4. Reached for Playwright when the CLI ran out of road. Playwright is a browser-automation tool — it lets a program drive a real Chrome window the way a person would. Type here, click that, wait for this thing to appear, take a screenshot. Claude used it through Playwright’s MCP server, which is the bridge that lets an AI drive a Playwright browser directly without me writing any glue code in between.
5. Uploaded files Playwright-style. For PDFs and slide decks the CLI couldn’t reach, Claude drove a Chrome window: opened the notebook, clicked “Add source,” dropped the file into the upload box, waited for a green checkmark.
6. Triggered video generation and waited it out. Claude opened the Studio panel (the right-hand area where Audio and Video Overviews live), clicked “Generate Video,” and then polled — that is, refreshed and looked — every 60 seconds until the video link appeared. Polling matters here because video generation can take ten or fifteen minutes; you don’t want the script to give up early or sit there refreshing manually.
7. Took screenshots all the way through. Every step Playwright did, Claude saved a screenshot. So if anything went sideways, I had a visual paper trail of every page the bot saw, in order. Debugging stopped being “it didn’t work” and became “here’s the page it landed on, here’s the button it clicked, here’s what it saw next.”
8. Paused at every destructive moment. Per my standing approval-gate rule, Claude waited for me to say yes before each upload, each video kickoff, each download. Speed without recklessness.

The whole thing — deciding which tool to use when, sequencing the calls, recovering from the gaps, knowing where to stop — was Claude’s call. I never had to know what a Python virtual environment was. I just had to know what a finished episode looked like.

Why this is a bigger deal than the NotebookLM trick

Take the NotebookLM-shaped hole out of this story and look at the shape of what’s left. Any time a piece of software you want to use at scale doesn’t have a tidy API:

• Someone, somewhere, has probably published a community workaround on GitHub.
• Claude Code can read that GitHub repo and use the workaround, even if you can’t.
• For the gaps where the workaround stops, an AI driving a real browser through Playwright can finish the job.
• You sit in the director’s chair, describe what you want in English, and approve the moments that matter.

That’s a different relationship to software than most non-coders have ever had with it. The bottleneck stops being “do I know how to code this?” and starts being “can I describe what I want clearly enough?” Those are extremely different bottlenecks. The second one is a thing most operators are already excellent at — it’s just that until recently, “describing it clearly” wasn’t a way to make a computer do anything.

It is now.

The caveats nobody mentions

Unofficial tools are unofficial for a reason. Two things you should know before you go this route:

• It can break tomorrow. Google ships UI updates (changes to what buttons and pages look like) and quiet backend changes (changes to the invisible plumbing the website runs on) constantly. The unofficial CLI works because it watches what the web app sends and copies the pattern. When Google changes the pattern, the CLI stalls until the community updates it. Same with Playwright — if a button gets renamed or moved on the page, the script clicks the wrong thing. The good news is Claude can usually detect the mismatch (the screenshots stop matching) and tell you what broke.
• You’re outside the official terms. Google might not love community tooling that hits the same internal addresses their own app uses. If you’re shipping something commercial that depends on this, that’s a real risk to think through. For a personal course like mine, I treated it like driving an old car — fine for now, accept that the part might not be there next year.

The fix for both is the same: back up your work the moment the pipeline finishes. Once a video is generated and downloaded, it’s yours. The pipeline that produced it is just scaffolding.

The pattern, if you want to try this yourself

If you’re trying to do something at scale on a tool that doesn’t have an official API, this is the rough order I’d hand to Claude Code:

1. “Check for an official API first.” If it exists, use it. Boring, supported, predictable. Most of OpenAI, Anthropic, and Google’s other tools have one — NotebookLM is the odd one out.
2. “Search GitHub for a community CLI. Here’s the link.” If a Python or Node tool exists (Node is just another popular programming language, like Python’s cousin), you get most of the speed of an API with most of the predictability. Claude reads the README and tells you the limits.
3. “For anything visual or login-gated, drive a real browser with Playwright.” Slower, more brittle, but it can do anything a person can do in a browser.
4. “Pause and ask before anything destructive.” Every upload, every generate, every publish should sit behind an approval gate. That’s the difference between a useful pipeline and one that costs you a Saturday cleaning up.

Each of those is a sentence, not a script. That’s the whole point.

For more context on the tool itself, Grokipedia’s NotebookLM entry covers the product timeline and the Audio/Video Overview history. NotebookLM’s own site is the right place to start if you want to try the official version first. Playwright’s own docs describe it as “reliable end-to-end testing for modern web apps,” which is a quiet way of saying “a robot that can use any web app you can use.”

The takeaway

The real unlock here isn’t the unofficial NotebookLM tool. It’s that the gap between “an idea I can describe” and “a working pipeline” is now a few sentences and a GitHub link. Claude Code stitches the rest together — the install, the orchestration, the fallback, the screenshots — based on plain English.

I shipped a cinematic series for a course without writing a line of code. The community built what Google didn’t. Claude assembled what neither shipped. I just told it what I wanted.

That’s the model worth taking forward.