API wishlist

Hey @Erica and @Shida,

there are a few features that I still would love to have in the API (for my android app):

All of this should be pretty straightforward to add and would make the app so much better.


1 Like

We’ve just been able to address the newly inserted item ID issue! Will look into adding the other stuff soon.

1 Like

Thank you, that was the most pressing issue. The others are just nice to have.

Use case: get node, get text, get date created/modded, insert date into text into node.

@Shida any updates on this?

Thanks for the ping, we’ll make sure this gets resolved before end of month. Sorry about the delay!

1 Like

Just an update - We’ve implemented this and it’s scheduled to go out around this weekend.

That is amazing Shida! Thank you, looking forward to it.

Any chance we will also get an API for file upload at some point? @Shida

1 Like

I can get that to work after March’s improvements that we’re currently working on. Also we just deployed the new APIs for the missing metadata!

1 Like

Just out of curiosity, is this being worked on already?

1 Like

I haven’t started on this yet but it’s already tracked and assigned to our next up list.


Would love to see an API for uploading files/pics. I would use it on my iPhone with Shortcuts as a way to fix the issue that only pictures can be uploaded.

1 Like

Update: upload files is now added.


Also, please consider adding an API endpoint to get the contents of a specific node.

Hi Sundar,

Nodes are not stored individually on our server, so the server will do more work if it were to find the specific node in the document for you. It would be fastest to pass the entire document alone and you can walk the tree to find the node.

Are you running into rate limiting issues? We recently raised the limit, realizing some folks need to have things updated pretty often.

You don’t store individual nodes? That’s the only way I could imagine storing it unless it’s a flat document.

We used to store nodes separately as rows in the DB table but at some point, we realized that DB performance would be quite bad since rows from multiple documents would start to get shuffled around inside the billion-row table and even properly indexing the table it would be quite a disaster for the DB to constantly fetch from multiple sectors.

More than 3 years ago we decided to move all node data to be stored in a per-document blob.

The biggest deciding factor was that the most frequent operations done were on a per-document level, meaning there’s a lot of node lookups in parent-child relationships, changes to multiple nodes under the same document, etc… which usually happened all at once per sync attempt.

Downloading a specific document as a ZIP file would be a very handy feature to have.

In the same format as our daily backups (with txt and opml formats)?