Nice, didn't notice that! (For those interested, it's actually documented here: https://developers.filepicker.io/docs/web/#fpurl-contents https://developers.fil

Nice, didn't notice that! (For those interested, it's actually documented here: https://developers.filepicker.io/docs/web/#fpurl-contents https://developers.filepicker.io/docs/web/#fpurl-contents) A 501 sounds like the closest error code, and I'd say having both asynchronous and synchronous modes of locking might be useful. Synchronous just holds the connection open (certain frameworks don't mind long-lived connections) while an asynchronous method might pass in a callback_url in the request to be hit when the file is ready, in the case of lockage. (NB: to be honest I'm not too sold on the demand for locking vs ovewriting, I guess I threw it in the list of [things that files can do]. Might be interesting to see this need evolve as files move to the "cloud" though.) EDIT: While I'm at it, a PUT method for creating files could be cool too, to let people use filepicker without the JS widget. // oops, missed the link. meant to reply to sibling comment