API wishlist

⚙Developers
#3

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

#4

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

#5

@Shida any updates on this?

#6

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

1 Like
#7

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

#8

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

#9

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

1 Like
#10

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
#11

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

1 Like
#12

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

2 Likes
#13

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
#14

Update: upload files is now added.

2 Likes
#15

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

#16

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.

#17

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

#18

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.

#19

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

#20

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

#21

Yup, that’d be ideal.

#22

I’ve got a couple of items I’d like to add to the wishlist:

  • Moving items between documents (API)
    • I’m not sure how the native clients deal with this - if they re-create & delete, then maybe just being able to optionally include the created date in the insert would be enough to mimic a ‘move’ between files.
  • API to rename/delete tags
    • Are tags stored/indexed separately on the backend? Or are clients doing the work? The latter would make sense if the data is stored as a single document blob.
  • Ability to change a node’s collapsed state
    • I’d like to be able to set this value on the initial ‘insert’ of a node, as well as the ability to toggle it for an existing node.

Overall, great work on the API! I haven’t had any issues yet.

Nick