Calling the Share URL with the Share Password within, so user won't need to see the password page

How can I call the Share URL with the Share Password within, so an user won't need to see the password page?

I've built this batch that builds some reports, store them on a proper ownCloud folder, them cUrl the /share API, with parameters for read-only public share (since my report clients are random internet users that request reports on-demand now and them) along with a random generated password that I deliver to him on another place.

So, my client doesn't ever get an account on my ownCloud.

This is my REST call, so other users may help or learn:

And with it:
permissions: 1
path: ownCloud Manual.pdf
shareType: 3
password: abc123
Content-Type: application/x-www-form-urlencoded

And I get as response:

And I insert a "/download" at the end and the direct download URL is perfect to deliver to my client, like this:

So far, so good, the URL works fine, but my client still stops at a page where he needs to enter the password (in this example: abc123), which is BAD, because, as designed, a Client will access this URL with his own Batch doing some cUrl. And his batch won't be able to interact with a screen.

Finally, the question: is there a way to supply the password at the same call for the share/download link?

Something like calling for:
...with a Request Header like: "password" : "abc123" ?

Then why do you need a password at all? The shared-id is already a random string, a password would be just another string.

As a double check. Once my batch generates a file and place it on its ownCloud space, it will call the /share and save the return. Another system will deliver it to my client's batch through an API.

Probably, the client's batch will them connect to the HTTP, and this call will be logged on file by common proxies or by some cURL lib, so I want him to send the password on the request, on a hope that both infos won't be logged

Usually, a Batch developer recognizes a "password" as something to hide, and won't just log it down. The opposite effect happens with an URL.

Also, I will document that his password is private and exclusive, so that he should take precautions to hide or we won't be held responsible if his download quota is overcharged due to malicious use.

Not exactly a system concern, like you pointed out, but a business enforcement / agreement.

There was a way to do this, I don't remember exactly, did you try the share-id as username?

do you know which PHP processe this share password? I can reverse-engineering it, but I am not familiar with the source yet, so a starting point would help, please

Sorry, I don't know that. If you want a quick hint, you can always try to ask someone via irc.