Logseq API: Connect Notes to an AI Workflow
Logseq's HTTP API lets local tools read and write your graph while it is open. Here is what that connection can do, where it stops, and how to build a scoped notes-to-AI workflow around it.
Updated 4 min read
Logseq's HTTP API lets a local process read and write your graph while the desktop app is running. You can query blocks, create new pages, and update properties through simple requests. Tools like fenbs work alongside this by holding the project tasks and decisions that belong outside your notes, so connected AI assistants have both the notes and the approved context when they work.
The API is a developer feature. It is off by default and only works when the Logseq desktop app is open on the same machine. Understanding those limits before you build saves time.
What the Logseq API can and cannot do
The Logseq HTTP API exposes your local graph over a configurable port. A script running on the same machine can query blocks by content, read page properties, insert new blocks, and update existing ones. The API is synchronous with the open app, so changes appear in your graph immediately.
The API does not work when Logseq is closed or when the graph is on a remote machine. It does not sync across devices by itself, and it does not give a cloud service direct access to your notes. If you want an AI assistant running in a browser or a remote tool to read your Logseq content, you need to export or copy the relevant content to a place that service can reach.
How to enable the API
In Logseq desktop, go to Settings, then Developer mode, and enable the HTTP API server. You can set the port and an authorization token. Keep the token private; treat it as you would any API credential.
Check Logseq's own documentation at https://docs.logseq.com for the current endpoint list and any version-specific changes, as the developer API has changed between releases.
Scoping the workflow to one section
Start with a narrow job rather than reading the whole graph. A useful first workflow picks a single namespace or tag, reads those blocks, and sends them to an AI assistant with a specific question. Say a design team tags each client decision with #approved. A script queries that tag, collects the blocks, and passes them to an assistant for a summary. That is a bounded job you can test and verify.
Keep the AI output separate from the notes it read. Writing the summary back into Logseq as a new page is reasonable. Overwriting source blocks with generated text mixes human notes and AI output in a way that is hard to untangle later.
Keep work decisions alongside your notes workflow
fenbs holds the project tasks and decisions that your notes workflow depends on: which namespace to query, what the assistant is allowed to update, and what counts as a correct output. Connect a supported AI assistant from Integrations and it reads those rules before working, so each run starts from the same agreed setup. fenbs does not read your Logseq graph directly; it holds the work around it.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Connecting an AI tool to the local API
A locally running script is the most direct approach. Write a function that calls the Logseq API, processes the blocks, and then calls your chosen AI provider API with the result. Trigger it manually or on a schedule with a task runner. Keep the Logseq token and the AI provider key in separate environment variables; neither belongs in the script itself.
For approval workflows around AI-generated outputs, see the AI agent approval workflow guide. For more on keeping tasks and decisions alongside any notes workflow, see the AI brain guide.
Keeping the AI output reviewable
When an AI assistant generates content from your notes and writes it back into Logseq, establish a review step before that content is used. A summary that looks plausible but misrepresents a source decision causes more harm than a missing summary.
One practical approach: have the script write AI output to a dedicated review page with a date stamp. Treat that page as a staging area. Move content to its permanent location only after you have read it. Over time, you learn which queries produce reliable output and which need more supervision.
Also consider the volume of output the script could produce. A script that runs once a day and writes one summary is easy to review. A script that runs on every save and writes a paragraph is quickly overwhelming. Set a deliberate cadence before automating, and err on the side of less frequent output until you trust the quality.
Where this workflow breaks down
If you want the workflow to run without Logseq open, or from a remote machine, the local API is not the right tool. In those cases, export the relevant content to a format a remote service can read, or use Logseq's sync export to push notes to a location your AI tool can reach. The local API is best for scripts you run yourself, on your own machine, while working.
How to do this with fenbs
- Create a free account. Add a project for the notes-to-AI workflow.
- Add tasks for each step: enabling the API, writing the query script, and testing with one section of your graph.
- Open Decisions and rules and record which namespace or tag the script is allowed to read, what the assistant is allowed to write back, and any restrictions on the content.
- Connect a supported AI assistant from Integrations. It reads the project context before working, including those rules.
- After each test run, save progress in fenbs: what the script returned, whether the output was correct, and the next step.