Yes and no, and the honest answer changed during 2026. Google does publish an\nAPI for Gemini Notebook Enterprise, in preview, behind a Cloud project and a\nlicence. The consumer NotebookLM you log into with a personal Google account\nstill has no developer key, and the standalone Podcast API that some posts\npoint at is deprecated and not taking new customers.
\nMost answers you will find say flatly \"there is no API\". That was true and is\nnow wrong, which is worse than either.
\n\nGoogle documents a REST surface for Gemini Notebook Enterprise, including\nnotebook operations and audio overviews — a notebook holds one audio overview\nat a time, created through notebooks.audioOverviews.create. It is marked\npre-GA, which means the terms and the shape can both move.
The access path is the part people miss. It needs a Google Cloud project and a\nGemini Enterprise or Education Premium licence, set up by an administrator. It\nis not a key you sign up for on a developer console, and it does not reach the\nnotebooks in your personal account.
\nDeprecated. Google is not allowlisting new customers for it. If a tutorial\ntells you to request access, that tutorial is out of date.
\nCommunity projects that drive the same interfaces the web app uses. There are\nseveral, in Python and in Node, exposing them as a CLI, as an MCP server, or as\na local REST API. They work, they are fast, and they reach your own notebooks\nwith your own login.
\nThey also share one honest caveat: nothing about those interfaces is promised.\nGoogle can change them, and when it does the project breaks until someone\nfixes it. That has happened — the mid-2026 interface rebuild broke every such\ntool at once.
\nThree questions settle it.
\nDo you have an enterprise licence and an administrator? Then use the\nofficial API. It is supported, it is the only route with a contract behind it,\nand nothing below competes with that.
\nDo you need your own personal notebooks? Then the official API is out, and\na community tool is the only route that exists.
\nDo you need it to keep working unattended? Weigh how quickly the project\nyou pick has recovered from past breakages. That is the only signal that\nmatters, and the commit history tells you more than the README.
\nOur own route is both an MCP server and a local REST API, so an agent and a\nworkflow tool can use the same install.
\n# Claude Code
/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields
# Then log into Google once, in a terminal
npx -y -p @roomi-fields/notebooklm-mcp notebooklm-mcp-setup-auth
Node 22 or newer. The REST route is in the install guide, and the\nfull endpoint list is in the API reference.
", "url": "https://notebooklm.roomi-fields.com/blog/does-notebooklm-have-an-api", "title": "Does NotebookLM have an API? The 2026 answer", "summary": "Google now ships a Gemini Notebook Enterprise API in preview, the standalone Podcast API is deprecated, and the consumer product still has no developer key. What each route actually gives you.", "date_modified": "2026-10-18T00:00:00.000Z", "author": { "name": "Romain Peyrichou", "url": "https://github.com/roomi-fields" }, "tags": [ "notebooklm", "api" ] }, { "id": "https://notebooklm.roomi-fields.com/blog/mcp-server-listening-on-0-0-0-0", "content_html": "Until version 4.0.0 this server bound to every network interface, accepted any\nbrowser origin, and required no credential on any of its 45 routes. Anyone on\nthe same Wi-Fi could drive it. Any web page you visited could drive it too.
\nSomeone reported it. We fixed it, published the advisory, and then found a\nsecond hole of the same family a few weeks later. Here is what we learned,\nwritten down because the pattern is not ours alone — researchers scanning\npublic MCP servers keep finding the same three mistakes.
\n\nIt means the server answers on your laptop's address on the local network, not\njust on localhost. On a home network that is your household. On café Wi-Fi,\na conference network or a shared office, it is everyone within reach.
What they get is whatever your tools do. For us that was reading your\nnotebooks, adding sources, generating content and sharing a notebook publicly.\nFor other servers it has been arbitrary code execution — Penpot's MCP server\nand MCPJam's inspector both shipped unauthenticated execution endpoints bound\nto every interface.
\nThe exposure is not exotic. A survey of reachable MCP servers found hundreds\nwith this shape, and a large minority with no authentication mechanism at all.
\nNo, and this is the part that surprises people. A web page you visit can make\nrequests to localhost from inside your browser. If the server answers them,\nthe page is driving your tools with your session, from the outside.
That is not theory. CVE-2025-49596 in the MCP Inspector scored 9.4 precisely\nbecause a malicious site could reach a service listening only on loopback and\nget to code execution.
\nThe defence is to refuse requests that carry a foreign origin, rather than\nmerely declining to send a permissive header back. Those are different things:\nthe second blocks the page from reading the reply, while the request still\nexecutes. For anything that writes, that distinction is the whole game.
\nBind to loopback by default, and fail loudly otherwise. Our server now\nrefuses to start on a public interface unless a token is set. Not a warning —\na refusal, because a warning in a log nobody reads is not a control.
\nRefuse foreign origins outright. Requests from an origin that is not\nallow-listed get a 403 before any handler runs, reads included.
\nRequire a token when exposed, and compare it in constant time. The\ncomparison detail is small but free: compare digests, not strings.
\nIn a container the first rule inverts — a published port is useless on\nloopback — so the entrypoint binds to all interfaces and exits with an\nexplanation if no token is set.
\nFile paths. Three of our tools take a path from the caller: one reads a file to\nupload, two write one. The data directory was an allowed root, and that\ndirectory holds the live Google session.
\nSo a document could tell an agent to add the session file as a source, and\nanother tool could then make that notebook public. Not a file leak — an account\ntakeover, via a tool that looks like it only reads documents.
\nThree things made it work, and all three are worth checking in your own code:
\n/data-evil passed a check for\n/data.If your server is stdio-only, it has no port and none of this applies. Most of\nthe risk arrives with the HTTP transport, which people add for n8n or for a\nremote machine and then forget is listening.
\n/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields
The full model, including what the container requires, is in\nthe security page. Past advisories are listed there too.
", "url": "https://notebooklm.roomi-fields.com/blog/mcp-server-listening-on-0-0-0-0", "title": "Your MCP server is probably listening on 0.0.0.0", "summary": "Ours was, for 45 unauthenticated routes, until a stranger reported it. What the exposure actually allows, why loopback alone is not enough, and the three controls that close it.", "date_modified": "2026-10-18T00:00:00.000Z", "author": { "name": "Romain Peyrichou", "url": "https://github.com/roomi-fields" }, "tags": [ "mcp", "security" ] }, { "id": "https://notebooklm.roomi-fields.com/blog/notebooklm-audio-overviews-programmatically", "content_html": "The audio overview is the feature that made NotebookLM famous, and the one\npeople most want to run in a loop — one podcast per report, per client, per\nweek. Doing that without clicking is possible by three different routes, and\nthey are not equivalent.
\n\nGoogle documents audio overview creation in the Gemini Notebook Enterprise\nAPI. A notebook holds one audio overview at a time, so a loop means creating\nnotebooks, not stacking overviews.
\nIt is pre-GA, and it needs a Cloud project plus an enterprise or education\nlicence with an administrator to turn it on. If you have that, stop reading —\nit is supported and nothing below is.
\nThe separate Podcast API that older tutorials point at is deprecated and not\ntaking new customers.
\nThe oldest community approach: a real browser clicks the same buttons you\nwould. It works, it reaches your personal notebooks, and it is slow — minutes\nper generation, most of it waiting.
\nIts weakness is the web app. When Google rebuilt the interface in mid-2026,\nevery selector moved and every browser-driven tool broke at once.
\nNewer tools call the same internal requests the web app makes, skipping the\npage entirely. Generation that took minutes through the browser takes seconds\nto kick off, and the result is read back directly rather than scraped.
\nIt is immune to visual redesigns, because there is no selector to break. It is\nnot immune to the interface itself changing, which is a different and rarer\nevent.
\nOur own server does this first and falls back to the browser when the internal\nroute does not answer — deliberately, because the two break for different\nreasons and rarely at the same time.
\nYou must own the notebook. Google refuses Studio generation on notebooks\nmerely shared with you. The refusal arrives as a permission status buried in\nthe response, which is easy to misread as \"the identifier changed\" — we lost\ntwo investigations to exactly that before reading the raw body.
\nOne overview per notebook. Plan the loop around notebooks, not around\ngenerations.
\nGeneration costs allowance. Usage is compute-based and refreshes every\nfive hours. Audio is one of the expensive features, so a batch will hit the\nceiling sooner than the same number of questions would.
\nThe download is not the obvious URL. The media link serves a viewer page,\nnot the file, so a naive fetch returns HTML that looks like a success.
\n/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields
npx -y -p @roomi-fields/notebooklm-mcp notebooklm-mcp-setup-auth
Generation, listing and download are covered in\ncontent management; the REST equivalents are\nin the API reference.
", "url": "https://notebooklm.roomi-fields.com/blog/notebooklm-audio-overviews-programmatically", "title": "Generating NotebookLM audio overviews programmatically", "summary": "A notebook holds one audio overview at a time, the standalone Podcast API is deprecated, and the official route needs an enterprise licence. The three ways to script it and what each costs.", "date_modified": "2026-10-18T00:00:00.000Z", "author": { "name": "Romain Peyrichou", "url": "https://github.com/roomi-fields" }, "tags": [ "notebooklm", "audio", "automation" ] }, { "id": "https://notebooklm.roomi-fields.com/blog/notebooklm-citations-as-json", "content_html": "NotebookLM's best feature is that every claim points at the passage it came\nfrom. Its worst export story is that those pointers stay in the web app. Copy\nan answer out and you get prose with little numbers in it.
\nIf you are feeding answers to anything downstream — a review, a database, an\nagent that must not invent — the citation is the part you actually need.
\n\nTwo things worth separating. The source name tells you which document a\nclaim came from. The excerpt is the passage itself, the few sentences the\nmodel drew on.
\nThe first is cheap to get and almost always enough to audit an answer. The\nsecond is what lets a downstream reader judge without opening the source, and\nit costs more to obtain.
\nAsk for a machine-readable citation format when you make the request. Our\nserver takes a source_format on every question:
| Value | You get |
|---|---|
none | the answer only |
inline | markers in the prose |
footnotes | markers plus a source list |
json | source names and cited excerpts, as data |
expanded | footnotes with the excerpts written out |
json is the one to use when something other than a person reads the result.\nexpanded is the one for a human report.
Because of where each lives. Source names sit in the answer's markup and come\nback in one pass. Excerpts are revealed by opening each citation, which means\nasking for each one in turn and collecting what comes back.
\nThat is slower, and it is why the two are separate options rather than one.\nIf you only need to know which document answered, do not pay for the rest.
\nThe pattern we keep coming back to: write each answer, with its citations, as\na document in a store you control — a vault, a table, a search index. Then\nquery that store instead of re-asking.
\nIt costs one pass through NotebookLM and nothing thereafter, which matters\nmore since usage became a compute allowance rather than a query count. It also\ngives you something NotebookLM does not: a corpus of past answers you can\nsearch, diff and cite.
\nWe emit those documents against a published schema so the shape does not drift\nbetween versions.
\n/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields
The request and response shapes are in\nthe API reference; the storage pattern is in\nthe RTFM integration page.
", "url": "https://notebooklm.roomi-fields.com/blog/notebooklm-citations-as-json", "title": "Getting NotebookLM citations as structured JSON", "summary": "NotebookLM shows citations as clickable markers in the web app and exports none of them. How to get the source names and the cited passages back as data an agent can act on.", "date_modified": "2026-10-18T00:00:00.000Z", "author": { "name": "Romain Peyrichou", "url": "https://github.com/roomi-fields" }, "tags": [ "notebooklm", "citations" ] }, { "id": "https://notebooklm.roomi-fields.com/blog/notebooklm-from-claude-code", "content_html": "Claude Code is good at reasoning and bad at knowing what is in your PDFs. If\nyou have already put those documents into NotebookLM, you can hand the agent a\nway to ask them — and get back answers that name the source and quote the\npassage, instead of a confident paragraph you then have to verify.
\nTwo commands and one login.
\n\nGrounding, and a way to show its work. A NotebookLM answer comes back with the\nsources it used and the exact passages it drew on. For an agent that matters\nmore than for a human reader: the agent can carry the citation into whatever it\nwrites next, and you can check it without re-reading the corpus.
\nIt also gains the Studio side — audio overviews, reports, mind maps, study\naids — which it can trigger and then collect.
\n/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields
That registers the server and an agent skill that teaches Claude when to reach\nfor it. Node 22 or newer.
\nThen log into Google once, in a terminal rather than through the agent:
\nnpx -y -p @roomi-fields/notebooklm-mcp notebooklm-mcp-setup-auth
A visible Chrome opens, you log in, and the session is saved. Run it in a\nterminal because the login can take minutes and an MCP client will time the\ntool call out first.
\nNotebookLM has no developer key for personal accounts. Reaching your own\nnotebooks means holding your own session, the way your browser does. That\nsession lives on your machine, outside the project directory, and it survives\nrestarts and days.
\nIt also means the session is worth protecting, which is why the server listens\non loopback and refuses to bind anywhere else without a token.
\nAsk the agent in plain language — \"what do my notebooks say about X\" — and let\nit pick the notebook. Under the hood it lists your notebooks, asks the\nquestion, and returns the answer with citations attached.
\nThe one option worth knowing is the citation format. Ask for the machine\n-readable one when the answer feeds something else: you get the source names\nand the cited excerpts as data rather than as footnote markers in prose.
\n/plugin marketplace update roomi-fields
/reload-plugins
There is no /plugin update. Full setup, including Cursor, Codex and the REST\nroute, is in the install guide.
PleasePrompto/notebooklm-mcp is the server most guides still point at. Its\nauthor archived it, and the package on npm has not moved since. If you\ninstalled it on the strength of a 2026 tutorial, you are running something\nnobody is fixing.
This is not a dunk. It was good work, it taught the pattern everyone else\ncopied, and the author said so plainly rather than letting it rot quietly.
\n\nNot immediately, and that is the trap. These tools drive interfaces Google\ndoes not document. They keep working until Google changes something, and then\nthey stop — all at once, for everyone.
\nThat happened in mid-2026, when the web app was rebuilt. Every project in this\nspace broke the same week. The maintained ones shipped fixes; the others\nstayed broken.
\nSo the question is not whether your install works today. It is who answers\nwhen it stops.
\nSeveral projects are active, in different shapes:
\nPick on language, on whether you need HTTP, and on how fast the project\nrecovered last time Google moved.
\nLess than you would expect. Most of its tool names were copied by everyone\nafter it, so an agent's habits largely carry over. In our case 17 of its 19\ntool names work unchanged.
\nTwo were renamed, because the thing they did grew: generating an audio\noverview became generating content of several kinds, and downloading audio\nbecame downloading content.
\nOne environment variable has the same name and a different meaning in\ndifferent projects. In the archived server, the transport variable chose\nbetween the stdio and HTTP ways of talking to the client. In ours, it chooses\nbetween the internal-API and browser ways of talking to NotebookLM.
\nCopy a configuration across without reading it and you will set something\nreal, that does something else, silently. Check every variable you carry over\nrather than assuming a shared vocabulary.
\n/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields
npx -y -p @roomi-fields/notebooklm-mcp notebooklm-mcp-setup-auth
The tool-by-tool mapping, the environment variable table and the full feature\ncomparison are on the migration page.
", "url": "https://notebooklm.roomi-fields.com/blog/notebooklm-mcp-archived-alternative", "title": "PleasePrompto/notebooklm-mcp is archived: what to use instead", "summary": "The most-recommended NotebookLM MCP server is no longer maintained. The alternatives, what moves when you switch, and the one environment variable that means something different everywhere.", "date_modified": "2026-10-18T00:00:00.000Z", "author": { "name": "Romain Peyrichou", "url": "https://github.com/roomi-fields" }, "tags": [ "notebooklm", "mcp", "migration" ] }, { "id": "https://notebooklm.roomi-fields.com/blog/notebooklm-multiple-google-accounts", "content_html": "One Google account gives you one allowance. Several give you several, and a\nserver that switches between them when one runs out keeps a long run moving.
\nThat is the whole idea, and it works. What is worth saying plainly is what it\ndoes not do, and what it asks you to hold on disk.
\n\nSince 2 September 2026, NotebookLM meters compute on a rolling five-hour\nwindow rather than counting chats per day. Rotation therefore multiplies a\nbudget, not a quota.
\nThe difference matters when you plan. With a daily count you could say \"three\naccounts, 150 questions\". With an allowance you cannot: the same three\naccounts carry a long conversation over forty sources far less far than they\ncarry short, fresh questions.
\nWhat you get is continuity — the run does not stop at the first exhausted\naccount — not a number to promise.
\nThe server keeps a session per account, notices the usage refusal, and moves\nto the next account that still has room. Each account has its own browser\nprofile, so switching does not disturb the one currently in use.
\nRe-authentication mid-run works the same way: the session for that account is\nrefreshed on its own profile, then promoted, rather than restarting\neverything.
\nNot in the project directory. They sit in the operating system's application\ndata directory, outside any repository by construction. That is deliberate —\nyou do not want a live Google session inside something you might commit or\ncopy.
\nOne consequence surprises people: sessions do not travel. Copying cookies\nfrom one machine to another fails. Google binds them server-side to the device\nand address that created them, even when the local expiry says they are valid.\nLog in on the machine that will run the work.
\nIt holds live logins. Anything that can read it can act as you.
\nWe learned this the uncomfortable way. Our own file-upload tool treated that\ndirectory as an allowed location, so a document could have told an agent to\nadd the session file as a source — and another tool could then have made the\nnotebook public. It is fixed, and the lesson generalises: check what your\ntools can reach, not only what they are for.
\nIf you run several accounts, you are concentrating several logins in one\nplace. Treat it accordingly.
\n/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields
Adding accounts, inspecting their state and forcing a switch are covered in\nmulti-account. Where sessions are stored, and how\nto move them, is in configuration.
", "url": "https://notebooklm.roomi-fields.com/blog/notebooklm-multiple-google-accounts", "title": "Running NotebookLM across multiple Google accounts", "summary": "Rotating accounts multiplies a compute allowance, not a daily quota. How automatic rotation works, where the sessions live, and why that directory deserves more care than most people give it.", "date_modified": "2026-10-18T00:00:00.000Z", "author": { "name": "Romain Peyrichou", "url": "https://github.com/roomi-fields" }, "tags": [ "notebooklm", "accounts", "quotas" ] }, { "id": "https://notebooklm.roomi-fields.com/blog/notebooklm-n8n-zapier-make", "content_html": "Zapier's NotebookLM page says the integration has not been built. Make has no\nmodule. n8n has no node. Every walkthrough you find does something adjacent —\nsaving files to Drive, which you then add to a notebook by hand.
\nThat is the honest state. What follows is the workaround that actually\nautomates the part people want: asking a question and getting a\ncitation-backed answer into the workflow.
\n\nBecause a connector needs an API with a key, and the consumer NotebookLM has\nneither. Google's documented API is the enterprise one, behind a Cloud project\nand an administrator. A connector built on it would serve the subset of users\nwho could already script it.
\nRun a small HTTP server on a machine your workflow can reach. It holds your\nGoogle session and exposes the operations as ordinary endpoints. Your workflow\nthen uses the same HTTP node it would use for any other service.
\nIn n8n that is one HTTP Request node: POST the question, read the answer and\nits citations out of the response, pass them to the next step. In Make and\nZapier it is their generic webhook or HTTP action.
\nThe answer arrives as data, so it can go to a sheet, a Slack message, a\ndatabase row or a document, like anything else in the workflow.
\nSomewhere the workflow engine can reach, which is the real constraint.
\nSelf-hosted n8n on the same machine is the simple case: the server stays on\nloopback and nothing is exposed. Cloud-hosted n8n, Zapier or Make cannot reach\nyour laptop, so you need the server on a host they can see — and at that point\nyou are exposing an endpoint that holds a live Google session.
\nIf you do that, set a token. Our server refuses to start on a public interface\nwithout one, which is deliberate: the failure is louder than a leak.
\nThe jobs where the answer is one step of several. A weekly digest that asks\neach notebook what changed. A support flow that answers from internal\ndocumentation with the passage attached. A research pipeline that files each\nanswer with its citations into a table.
\nThe pattern that pays best is answer-once-then-store. Usage is a compute\nallowance now, refreshed every five hours, so a workflow that re-asks the same\nquestion every run is spending for nothing.
\ngit clone https://github.com/roomi-fields/notebooklm-mcp.git
cd notebooklm-mcp && npm install && npm run build
npx -y -p @roomi-fields/notebooklm-mcp notebooklm-mcp-setup-auth
HTTP_PORT=3000 node dist/http-wrapper.js
Node 22 or newer. The worked n8n flow is in\nthe n8n guide; the full endpoint list is in\nthe API reference.
", "url": "https://notebooklm.roomi-fields.com/blog/notebooklm-n8n-zapier-make", "title": "NotebookLM in n8n, Zapier and Make: there is no connector", "summary": "None of the three has a NotebookLM integration, and Zapier says so on its own page. The workaround is a local HTTP endpoint your workflow calls like any other API.", "date_modified": "2026-10-18T00:00:00.000Z", "author": { "name": "Romain Peyrichou", "url": "https://github.com/roomi-fields" }, "tags": [ "notebooklm", "n8n", "zapier", "automation" ] }, { "id": "https://notebooklm.roomi-fields.com/blog/notebooklm-usage-limits-automation", "content_html": "If your script waits until midnight for the quota to reset, it is waiting for\nsomething that no longer happens. On 2 September 2026 Google replaced\nNotebookLM's fixed daily chat caps with a compute-based allowance that\nrefreshes every five hours, up to a weekly ceiling.
\nOur own documentation said \"50 queries per day, resets at midnight UTC\" until\nthis week. It was wrong, and we had been repeating it for months.
\n\nNot requests. Google's own wording is that limits are compute-based and depend\non \"the complexity of your prompt\" and \"the models and features you use\".\nChat length and the number of sources count too.
\nThe practical consequence: two scripts issuing the same number of questions\ncan consume wildly different amounts. A long conversation across forty sources\nis not the same purchase as forty short, fresh questions.
\nEvery five hours, on a rolling window, until you hit a weekly ceiling. There is\nno daily reset and no fixed hour to wait for. The remaining balance and the\nreset time are shown in the app under Settings → Usage, and in the chat\nwhen you get close.
\nPaid plans multiply the allowance rather than changing the mechanism — two\ntimes on AI Plus, four on AI Pro, more above that.
\nStop counting. A counter that stops at 50 either stops too early or too\nlate, and you cannot tell which.
\nPrefer short, stateless questions. Each one costs less than extending a\nconversation that carries its whole history. If you do not need the thread,\ndo not open one.
\nNarrow the source list. Asking against the three relevant sources instead\nof the whole notebook is cheaper as well as more accurate.
\nMake the run resumable. The allowance will run out mid-batch sooner or\nlater. A run that records each answer as it arrives loses nothing; a run that\nwrites at the end loses everything.
\nTreat the refusal as a signal, not an error. When the server reports the\nlimit, back off for the window rather than retrying immediately.
\nYes, with a caveat worth being clear about. Rotation moves work onto another\naccount's allowance when the first runs out. It multiplies a budget, not a\nquota, and it does nothing about the fact that you can no longer predict how\nfar that budget goes.
\nIt is also a per-account login each time, with everything that implies for\nwhere those sessions live.
\n/plugin marketplace add roomi-fields/claude-plugins
/plugin install notebooklm@roomi-fields
The batch pattern, including how to cache answers so a re-run costs nothing,\nis in running a thousand questions. Account rotation\nis in multi-account.
", "url": "https://notebooklm.roomi-fields.com/blog/notebooklm-usage-limits-automation", "title": "NotebookLM usage limits changed: what breaks in your automation", "summary": "Since 2 September 2026 NotebookLM meters compute on a rolling 5-hour window instead of counting 50 chats a day. Every script that planned against a daily quota is now planning against a number that does not exist.", "date_modified": "2026-10-18T00:00:00.000Z", "author": { "name": "Romain Peyrichou", "url": "https://github.com/roomi-fields" }, "tags": [ "notebooklm", "quotas", "automation" ] } ] }