But when trying to use it (from command line), it doesn’t seem to work.Like if the endpoint doesn’t exists. Am I doing somethiong wrong?
root@RUT956:/tmp/snmp# /sbin/api POST /package_manager/actions/upload_package '{"file":"@/tmp/snmp_2025-12-02-1_mipsel_24kc.ipk"}'
{"http_code":404,"http_body":{"success":false,"errors":[{"source":"Request","error":"Provided action is not available. Available actions: [update_package, update_multiple_packages, remove_package, remove_multiple_packages, install_multiple_packages, delete_install_files, install_package]","code":122}]}}
I have tested this on my end as well and can confirm that I was able to reproduce the same issue. As a result, I have forwarded this case to our R&D team for further investigation. I will keep you informed and provide an update as soon as I have more information.
Thank you for your answer. After far too much trial and errors, I finally managed to find how it works!
API Documentation and exemples could have been clearer.
/sbin/api POST /package_manager/actions/upload_package '@/tmp/package.tar.gz;package'
/sbin/api POST /package_manager/actions/install_package '{\"data\":{\"custom\":\"1\", \"package\":\"*\"}}'
The first is unzipping the package into a temporary opkg/custom_package directory. All the ipk’s inside the archive package.tar.gz are placed there.
The second command will effectively do the install but you MUST set a "1" ( surrounding double quotes " are VERY important) for the custom json key in data part otherwise it will go fetch the packages from the server. The package key is set to "*" to install ALL the packages from the custom_package folder. I guess you could install it one by one or eventually the “main” package of the group could require dependencies recursively which may result to the same.
If the custom key is set without the quotes it is simply ignored or interpreted as a zero which is the same
About my question above, I was effectivelly doing something wrong. But it also seem’s that the upload_package endpoint is missing from the returned error list. But, it exists nonetheless and is to be used with /sbin/api in a way that is quite obscure to me → the file is not set in the json part. Probably due to implementation specificities of /sbin/api to read files from disk.
I appreciate you sharing the solution that worked in your case. If you need any further assistance or have additional questions, feel free to reach out.