I've almost exclusively seen this handled using an upload with a temporary filename (usually convention based) and then renamed on completion. Watch then for the existence of the renamed files. Clean up temp files after a defined amount to time (30 days for example).
Does it have to be node.js? Are you looking to expand your JS skills, or do you just want a decent static site generator? (If B, then hugo is awesome, and awesome fast)
Useful article for someone needing help in revising a URI naming scheme, but beyond that could end up being harmful to that person's greater understanding of building "RESTful" systems.
For example, in the Idempotency section, the author states that for GET requests "no change in application state should occur" which is good, but then also states "the response should always be the same" which is incorrect. There's nothing that says the response cant change, if the resource has changed, but the constraint is that it cant cant _as a result_ of the GET request. This is an important distinction.
DELETEing a resource twice, the second delete should be a NOOP, not a 404.
There's some excellent NDC Oslo & London talks covering more in-depth RESTful topics that I'd recommend checking out if the content of the article is an eye opener for you.
I'll second the comment about On-boarding, follow up templated emails just serve to annoy me. I'll try out the product when I get a chance to. Maybe a simple 24 hour later email introducing support and asking if I've got questions and another follow up 2 weeks later. Nothing more.
Oh and please please please, put some effort into multi-account detection (if not a side project). It's really annoying / unprofessional to trigger off a new series of On-boarding emails just because I added a new org.
Also, price appropriately, just because your unlimited plan is stupidly priced wont make people thing the solo plan is reasonable if it's not. Ask your early customers what they're using and what features they'd use/pay for if individually offered to them.
They are also best avoided. Design for failure.