Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
Hey there,
I want to create an automated API Call to our company's Dropbox that creates a folder with only select user groups having access. To do that I am using the Dropbox "Make an API Call"-module in Integromat and "/share_folder". I have tested it both with a path that is an existing folder and with one that would create a new folder but every time I run the operation I get the error "The operation failed with an error. [401] missing_scope/".
I am an absolute beginner with this stuff but after doing some reading on this forum I suspect that the connection to Dropbox is read-only. Especially since API Calls like get_metadata or list_folders work just fine. What I am wondering is: How do I find out what kinds of permissions an app that is authorized within Dropbox has (Integromat in this case)? Should I ditch the pre-made module and just make the call using the generic HTTP modules?
Here is the full input I am giving the module:
URL: /2/sharing/share_folder (relative to https://api.dropboxapi.com)
Body: {
"path": "/not a machine cloud/projekte/2021/21012 - casefilm google barklaycard - acht - jm/test", "acl_update_policy": "editors",
"force_async": false,
"member_policy": "team",
"shared_link_policy": "members",
"access_inheritance": "inherit"
}
Dropbox API Endpoint: api
Method: POST
Headers:
Key: Content-Type
Value: application/json
Disable Dropbox API Path Root: false
Thanks a lot in advance!
Cheers,
Leon
@Leon_NAM wrote:...
Input:
... "gzip": true, ......
Hi @Leon_NAM,
You are using gzip encoding in your request. Dropbox API uses flat requests parameters (including passed as body) and any type of encoding can confuse it. Do you able forbid the encodings for all Dropbox API requests? 🧐
Let's see if this can help.
Hey @Здравко,
I tried that but it returns the same error.
Input:
[
{
"ca": null,
"qs": [],
"url": "https://api.dropboxapi.com/2/sharing/share_folder",
"data": "{ \"path\": \"/not a machine cloud/test\", \"acl_update_policy\": \"editors\", \"force_async\": false, \"member_policy\": \"team\", \"shared_link_policy\": \"members\", \"access_inheritance\": \"no_inherit\"}",
"gzip": false,
"method": "post",
"headers": [
{
"name": "Authorization",
"value": "Bearer <OAuth 2.0 Token>"
}
],
"timeout": null,
"useMtls": false,
"bodyType": "raw",
"contentType": "application/json",
"serializeUrl": false,
"shareCookies": false,
"parseResponse": false,
"followRedirect": true,
"useQuerystring": false,
"followAllRedirects": false,
"rejectUnauthorized": true
}
]
Output:
[
{
"statusCode": 400,
"headers": [
{
"name": "cache-control",
"value": "no-cache"
},
{
"name": "content-security-policy",
"value": "sandbox allow-forms allow-scripts"
},
{
"name": "x-content-type-options",
"value": "nosniff"
},
{
"name": "content-type",
"value": "text/plain; charset=utf-8"
},
{
"name": "accept-encoding",
"value": "identity,gzip"
},
{
"name": "date",
"value": "Thu, 16 Dec 2021 14:25:52 GMT"
},
{
"name": "server",
"value": "envoy"
},
{
"name": "content-length",
"value": "98"
},
{
"name": "x-dropbox-response-origin",
"value": "far_remote"
},
{
"name": "x-dropbox-request-id",
"value": "315f864799fa46c7a4c30fab485af071"
},
{
"name": "connection",
"value": "close"
}
],
"cookieHeaders": [],
"data": "Error in call to API function \"sharing/share_folder\": request body: could not decode input as JSON",
"fileSize": 98
}
]
Unfortunately I don't have more specific error information add here beyond the message that the parsing failed. The data shown here does appear to be valid JSON, but it's unclear if/how this may be being transformed when being set in the actual HTTPS request being sent. When I try this value myself with this endpoint just using curl I do not get this error, so it does some it's getting malformed by the client somehow. The best way to debug this would be to print out the actual request being sent.
I presume the \ characters are just to escape the quotes and are not being sent to the API, but that may be good to verify. Likewise, the extra whitespace shouldn't matter, but it may be useful to remove it to eliminate that as a potential issue.
you're right it's all a bit pointless when we don't know what the flat HTTPS request is exactly. I suspect there's something weird happening on Integromat's side of things as well. I have reached out to their support and am awaiting response. I will post here once they tell me what they think the issue is. Until then: Thanks and have a good one!
Hi there!
If you need more help you can view your support options (expected response time for a ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!