I have the following working curl request which I use to update my apps manifest in slack:
curl -D /dev/stderr -s -d app_id=<APP_ID> --data-urlencode manifest@manifest.json -H 'authorization: Bearer <CURRENT_TOKEN>' https://slack.com/api/apps.manifest.update
I am attempting to achieve the same result using python3 with the below:
import requests
currentKey = <CURRENT_KEY>
headers = {
'authorization': 'Bearer ' + currentKey,
}
data = {
'app_id': '<APP_ID>',
}
response = requests.post('https://slack.com/api/apps.manifest.update', headers=headers, data=data)
print(response.text)
This code will currently return an error:
{"ok":false,"error":"invalid_arguments","response_metadata":{"messages":["[ERROR]
missing required field: manifest"]}}
as I haven’t passed the manifest.json file which needs to be provided as url encoded data based on slacks docs. Can someone confirm what the best approach is with encoding and passing my files data to the request?
I’ve attempted different revisions of the upload using json
and urllib
to try and read in the file, encode it, pass it to an object and include it within the ‘data’ dict but none seem to return an accepted format.
Is the process I’m trying to take correct, or should I be looking to pass in the file via the files
option for requests
?
>Solution :
You’re correctly setting the app_id
key in your data, but you never set the manifest
key. You need something like:
import requests
currentKey = <CURRENT_KEY>
headers = {
'authorization': 'Bearer ' + currentKey,
}
with open('manifest.json') as fd:
manifest_data = fd.read()
data = {
'app_id': '<APP_ID>',
'manifest': manifest_data,
}
response = requests.post('https://slack.com/api/apps.manifest.update', headers=headers, data=data)
print(response.text)
If you compare the request generated by curl with the request generated by the above code (e.g., by pointing them at a local netcat process instead of slack.com
), you’ll see that the requests are now substantially identical.
You don’t want to use the files
option because this will result in sending a multipart/form-data
request, rather than a application/x-www-form-urlencoded
request, and it’s unlikely it would work (unless the documentation suggests otherwise).