I don’t think the details of an API matter that much. It’s for developers and hobbyists who will figure out how to work with whatever you provide as long as it’s reasonably stable: provide an API token that I can include in an HTTP request, expose a single useful endpoint (maybe “list children of $id”), then add more endpoints over time. If you get the API wrong, no big deal: freeze v1 and create v2 based on what you learned.
Yeah, over the years I’ve kept my eye on that one and another in Python. I don’t use Node or Python, so those aren’t much use specifically (most of my tools are in OCaml). Most of these tools also require disabling 2FA, which is not ideal.
More generally, I avoid things built on internal APIs because they have no assurance of stability. I’d rather not spend my time reverse engineering your internals or relying on others to do so. Dynalist was nice that way: I pay money and get a stable, supported API.
I listed my use cases at the top of this thread, but I’ll expound on them here in case that’s helpful. These are all things that I use the Dynalist API for right now.
creating tasks
I have two specific tools that use this API:
The first one is a command line tool where I run
$ task xxx yyy zzz
and it creates a new task beneath my Inbox node with title “xxx yyy zzz”. On Dynalist, this uses their Send to Inbox API. That API is especially helpful for this use case, but as long as each node in my tree has a stable identifier and there’s an API for creating a child for a specific node, it’d work fine.
My second use case for creating tasks is my private command line tool called habits. I run it each morning, and it calculates a list of tasks that should be added to my to-do list for today. Some of these recur daily, some are date patterns like “2nd Tuesday in May, June, and July”, others are more complex based on external data sources like weather or home automation data, etc. Anyway, this tool locates my “Tasks” node (a “File” in Dynalist; in Workflowy before I switched, it was just a child of the root node) then creates a new child node for each of the day’s new tasks.
More concretely, this use case needs a stable identifier for my “Tasks” node, a way to list all the children of that node so my habits tool can find the child for today’s date (“Tasks > Mon, 21 Jul 2025”), and a way to create child nodes within that node.
automating backups (not Dropbox)
I want daily backups of my lists saved to my own infrastructure. I don’t use Dropbox, so Workflowy’s daily backups there weren’t much use to me. Incidentally, this is a use case that the Dynalist API doesn’t handle either.
My old approach on Workflowy was, every morning, to manually “… > Export All > OPML > Click to download” then a local script noticed the new .opml file and saved it accordingly. On Dynalist, that workflow is “… > Download Backup” then the script notices the new .zip file, unpacks it, and saves the .opml accordingly.
a small terminal UI
I have a very primitive terminal UI (part of my task binary) that’s kind of like an old mail(1) interface. There’s a prompt, I enter small commands to view all children of the current node, “cd” to a different node, create a new node, etc. It’s not especially interesting, but I don’t always have a browser available or want the weight/complexity of one. Anyway, the necessary APIs are: list children of a given node, create a child within that node, delete a node, mark a node as complete.
My comments above about avoiding internal protocols apply here too.
I’m happy to give more detail on any of this that you want. I think the trick is to just offer some API, any API, and iterate from there.