converting curl url encoded data to python format

May 23, 2023

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).