Tana API: Plan a Notes-to-AI Workflow
Tana's Input API lets external tools add nodes to your workspace. Here is what the current access covers, where it stops, and how to plan a small integration before you build.
Updated 4 min read
Tana's external API gives tools a way to add nodes to your workspace. It is narrower than a full read-write API: the current access is primarily for writing new content in, not for querying what already exists. Understanding that scope before you plan an integration saves you from building something that the API cannot support. Tools like fenbs handle the project context and decisions around your integration, so a connected assistant knows what the workflow is allowed to do.
Check Tana's own developer documentation for the current state of the API, as access and capabilities have evolved over time.
What Tana API access currently covers
Tana offers an Input API that accepts structured data and creates nodes in a target workspace. You can send a payload of fields and values, and Tana creates a node matching your schema. This is useful for capturing data from external sources, such as a form submission, a webhook event, or the output of an AI workflow, directly into your Tana workspace.
Reading existing nodes, querying by content, or updating nodes through the API are not part of the standard Input API. If your workflow requires reading from Tana and acting on what it finds, you are working outside what the Input API provides. Check https://tana.inc for the most recent capability updates.
Planning the integration before you build
Before writing a line of code, write the workflow in plain language. What does the integration receive as input? What does it create in Tana? Who triggers it, and when? A three-sentence description is enough to identify whether the Tana API fits the job.
Say a research team wants an AI assistant to read a web article, extract three key points, and save them as a node in Tana. The input is a URL. The output is a structured node with a title and three child nodes. The Tana Input API handles that: it accepts the structured payload and creates the node. What it cannot do is let the assistant query Tana afterward to see whether a similar node already exists.
Choosing what the AI can write
Keep the scope narrow. Define a specific node schema before connecting any AI to it. Which fields are required? What are the allowed values for each field? A schema prevents an AI from creating nodes that do not fit the rest of your workspace.
Record those decisions somewhere the next developer, or the next AI assistant working on the integration, can find them. If the schema changes, the integration needs to change with it. A change made in Tana without updating the integration will create malformed nodes silently.
Hold the integration decisions outside Tana
Add the integration project to fenbs and record the agreed node schema, the approved use cases, and any restrictions on what the AI is allowed to write. Connect a supported AI assistant from Integrations and it reads those rules before working on the integration. fenbs does not connect to Tana directly; it holds the decisions and context that the integration depends on.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Testing the connection before relying on it
Send a test payload manually before wiring an AI into the workflow. Use a tool like curl or a simple script to confirm the node appears in Tana with the correct fields. Check the node schema in Tana after each test to catch field mismatches early.
Set up a test workspace or a test supertag separate from your live workspace. AI-generated content is easier to review and correct when it lands somewhere contained rather than mixed with your active notes. Move approved nodes to your real workspace after review.
Keeping the node schema in sync with Tana
A node schema defined in code and a supertag structure in Tana need to stay aligned. When someone adds a required field to the supertag in Tana, the payload the integration sends will be missing that field. The integration will either fail or create nodes that do not match the supertag template.
Assign someone to own the schema on both sides. When the Tana supertag changes, that person updates the integration payload. When the integration changes, they check whether the Tana supertag needs to change too. A schema mismatch that produces wrong nodes is harder to clean up than one caught at the source.
When this workflow is not the right fit
If your workflow needs to read from Tana as well as write to it, query existing nodes, or update nodes in place, the current Input API is not enough. In those cases, exporting your Tana content to a format an AI can read, and keeping the integration results in a separate record, is a more reliable path. See the AI agent approval workflow guide for more on keeping human review in AI-to-notes workflows.
How to do this with fenbs
- Create a free account. Add a project for the Tana integration.
- Add tasks for each step: defining the node schema, writing the payload script, and testing with a sample input.
- Open Decisions and rules and record the approved schema, the trigger conditions, and any review step before nodes go into your live workspace.
- Connect a supported AI assistant from Integrations. It reads the project context before working, so each run follows the agreed schema.
- After each test, record in fenbs what the node looked like, whether it matched the schema, and the next step.