[Tana -> Other Services] ✦ Make all Tana content available via API

1000% — Tana is proving to be a game-changer for our organization. We use it for meeting notes and agendas, technical documentation, and ephemeral tasks that don't warrant an issue in our main issue tracker (Linear.)

For us, the benefits of an API would be huge, allowing Tana to act as a heads up display for things happening in other services (such as updates on Linear tasks, calendar agendas), as well as allowing Tana to feed data into other systems optimised for particular tasks.

Use cases, Tana -> Other Services

• Watching for new or updated nodes with a certain tag, and syncing them to other services. Examples:
  • Pushing #tools from Tana to Airtable, which we use as a CMS.
  • Pushing #leads from Tana to our CRM and financial forecasts
  • Pushing issues to Linear
  • Drafting proposals and pushing them directly to our automated-proposal-generator
• Creating embeddings or fine-tuning models based on our Tana database, enabling things like:
  • Conversational UI for solving customer support queries, based on our Tana documentation.
  • Automating proposal drafts based on meeting notes
• Rolling our own front-end for our organizational operating system

Use cases: other services -> Tana

• Using Zapier + OpenAI to summarise project updates/movements directly into our daily pages
• Automatic feed of upcoming meetings in our daily/weekly pages

It would be a huge level-up for us! The flexibility of Tana's data structure is what attracted us to the service—in the medium-long term an API will be absolutely essential to our workflows.

I might suggest changing this problem to be renamed "I want my Tana data in other places".

An API would be a big step towards opening up Tana to all sorts of use cases that can't all be encapsulated here. This would effectively create a plugin environment for Tana, and allow Tana to capitalize on the open source community that would be interested in building these tools. This could first be a read-only API, with later consideration given to whether writing should be enabled as well.

For what it's worth, the main use cases I would be interested in for an API would be

• querying nodes, or a subset of nodes to published on a website
• exporting entire graph to be stored as markdown files in my own archival system

💯 With great APIs for reading and writing nodes, Tana could be both the backend and the UI layer for building apps and internal tools to manage your life and work.

Nice feedback from Quentin from the WeWeb Team: "I think you can begin using it with the REST API plugin, but I’ll add it to our list of future integrations!" https://community.weweb.io/t/integration-with-tana/2828/2

Really hope that a feature like this is in the pipeline!

Airtable's API is one of the best implementations I have seen. You get an API that aligns with your own data's schema. https://airtable.com/developers/web/api/introduction

I could imagine a similar approach working really well with Tana. These are the sorts of requests I could imagine finding really useful:

• GET /supertags/<supertag_id>/list_nodes would give you a list of all nodes tagged with that supertag
• GET /node/<node_id> would give the content for a particular node
• GET /node/<node_id>/descendants would give you a list of all nodes nested under a particular node. This would be particularly useful when applied to a search node.

I would suggest to broaden the idea here.

What I would look for is an abstraction that would allow us to bring in objects from outside Tana in a “managed” supertag. One example is a Readwise integration, which could fully sync (two-way) with the Readwise API. I just don't see why it should be limited to Readwise. The same abstraction is useful for todo lists like Todoist, for calendar entries say on Google Calendar, for encrypted notes stored elsewhere. The possibilities are truly endless.

For me, what resonated with Tana is the treatment of queries as “first class citizens”. I'm hopeful data integrations to Readwise, Todoist, Google Calendar, etc., could be too!