Get a folders public link using the dropbox API in Azure logic apps

@Jeff B.63 wrote:
The example in the blog uses curl but I need HTTP. I tried the online conversion tool from GitHub but it just gets syntax errors. ...

Hi @Jeff B.63,

You can add -v option (verbose) in every curl command and you'll get entire HTTP request in the console output as is. 😉

@Jeff B.63 wrote:
... I have my AppKey and AppSecret but what is the authorization code and do I need a redirect URI since I want the response to come right back to the HTTP request?

The authorization code is something you should receive from the authorization page where you (or your application user - whoever is) grant permission to access account resources. It can be copied by hand or received automatic using redirect URI - the choice is yours. So, no, it's not mandatory usage of redirect URI. Take a look here how you can perform the same without redirect URI.

Hope this helps.

All comments

The Dropbox API does offer the ability to create and retrieve shared links programmatically.

To create a shared links for a file or folder, you should call the /2/sharing/create_shared_link_with_settings endpoint. To retrieve existing shared links, you would call /2/sharing/list_shared_links.

By the way, those are links to the documentation for the HTTPS endpoints themselves, but we recommend using one of the official SDKs if possible. Those have corresponding native methods for the HTTPS endpoints.

This is a little outside my wheelhouse but I am giving it a go. This is what I have tried but something is wrong and I am not sure if I am on the right track or not. Some guidance would be appreciated.

Dropbox api call.png

Here is the raw input:

{

"uri": "https://api.dropboxapi.com/2/sharing/list_shared_links",

"method": "GET",

"queries": {

"direct_only": "true",

"path": "/~ Pictures - All/2023/236056 - 459 Jellicoe Cres/"

"headers": {

"Authorization": "*sanitized*",

"Content-Type": "application/json"

}

And here is the raw output:

{

"statusCode": 404,

"headers": {

"Date": "Mon, 24 Apr 2023 20:37:35 GMT",

"Server": "envoy",

"Vary": "Accept-Encoding",

"X-Dropbox-Response-Origin": "far_remote",

"X-Dropbox-Request-Id": "43295fb3e28a44578e11c9600a9e2579",

"Transfer-Encoding": "chunked",

"Content-Type": "text/html"

Error (404) We can't find the page you're looking for.

}

@Jeff B.63, Take a look on documentation! There POST request is always used. 🙋 GET is not for listing. The call parameters have to reside in request body, JSON encoded (as you correctly have specified in a header). Where is this JSON right now? 🧐😉

@Jeff B.63 As Здравко noted, your request is not formatted properly. You can find information on how to call the endpoint in the documentation. The API v2 Explorer can also be useful for prototyping these calls; you can click "Show Code" to see how the call would be constructed in a few different clients.

After a long while I am finally getting back to this issue.

I have tried the API v2 Explorer and can get the call to work but when I view the code for HTTP, my logic app has all the same content with the exception of User-Agent which in the Explorer shows as

User-Agent: api-explorer-client

Do I need to insert my own API name in there for the app that I created and has the same API Key?

@Jeff B.63 wrote:
..., my logic app has all the same content with the exception of User-Agent which in the Explorer shows as... Do I need to insert my own API name in there for the app that I created and has the same API Key?

No, you don't need to change it at all. "User-Agent" header doesn't participate in any way to authentication or in endpoints behavior.

@Jeff B.63 Здравко is correct; while the 'User-Agent' value is meant to contain the app's name, it does not impact the functionality of the API call.

If the call is still not working for you, make sure the app is formatting the request correctly. It may help to print out the actual HTTP request, if possible. (If you share that here, be sure to continue to redact the access token though.)

I am getting the error

Error in call to API function "sharing/create_shared_link_with_settings": Unexpected URL params: "path"

The JSON for that HTTP request was:

{

"uri": "https://api.dropboxapi.com/2/sharing/create_shared_link_with_settings",

"method": "POST",

"queries": {

"path": "D:\\DRYBSMT Dropbox\\Jeff Brown\\~ Pictures - All\\Share Link Testing\\1"

"headers": {

"Authorization": "*sanitized*",

"Content-Type": "application/json"

}

In the Logic Apps HTTP step, the code view looks like this:

{

"inputs": {

"method": "POST",

"uri": "https://api.dropboxapi.com/2/sharing/create_shared_link_with_settings",

"headers": {

"Authorization": "*sanitized*",

"Content-Type": "application/json"

"queries": {

"path": "D:\\DRYBSMT Dropbox\\Jeff Brown\\~ Pictures - All\\Share Link Testing\\1"

}

The code produced by the API Explorer is:

POST /2/sharing/create_shared_link_with_settings
Host: https://api.dropboxapi.com
User-Agent: api-explorer-client
Authorization: *sanitized*
Content-Type: application/json

{
    "path": "D:\\DRYBSMT Dropbox\\Jeff Brown\\~ Pictures - All\\Share Link Testing\\1"
}

The Logic Apps HTTP data window looks like this:

Finally, the section of the overall JSON that applies to the request is this:

"HTTP": {

"inputs": {

"headers": {

"Authorization": "*sanitized*",

"Content-Type": "application/json"

"method": "POST",

"queries": {

"path": "D:\\DRYBSMT Dropbox\\Jeff Brown\\~ Pictures - All\\Share Link Testing\\1"

"uri": "https://api.dropboxapi.com/2/sharing/create_shared_link_with_settings"

"runAfter": {

"Compose": [

"Succeeded"

]

"type": "Http"

}

@Jeff B.63 It looks like you are supplying the "path" parameter as a URL parameter; it instead needs to be supplied in JSON in the request body. You can find more information in the documentation for the /2/sharing/create_shared_link_with_settings endpoint, as well as the documentation for the RPC format it uses.

You can also use the API v2 Explorer to see how the call should be constructed. For instance, click "Show Code" and select "View request as" "HTTP request".

By the way, your path value doesn't look like a valid Dropbox path. It looks like local Windows file path. I suggest reading the File Access Guide for information on interacting with files on the Dropbox API.

Yes, sorry, I accidentally used the local path when creating the post but I have been using the correct path in my testing.

I have looked through the documentation as well as used the API Explorer.

The code produced by it under HTTP is:

POST /2/sharing/create_shared_link_with_settings
Host: https://api.dropboxapi.com
User-Agent: api-explorer-client
Authorization: *sanitized*
Content-Type: application/json

{
    "path": "\\~ Pictures - All\\Share Link Testing\\1"
}

When I look at the JSON for the Query in the HTTP step, it is identical to what the Explorer is showing.

@Jeff B.63 I see you have changed the parameter data to be JSON, but you still have it in the "Queries" section for your client. I can't offer support for your client itself, but it appears your client sends that as URL parameters. That JSON needs to be sent in the request body, so you probably need to put that in the "Body" section instead.

Also, the path value itself still doesn't look correct. It looks like you would want something like this:

"/~ Pictures - All/Share Link Testing/1"

Thank you for your help. I was able to get it working finally. I am just not sure which reply to mark as the answer.

My next quandary is keeping or refreshing the token so it doesn't expire. Can you point me in the right direction?

@Jeff B.63 Dropbox issues short-lived access tokens which expire after a few hours. Apps can get long-term access by requesting "offline" access, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention. Refresh tokens do not expire automatically and can be used repeatedly. You can find more information in the OAuth Guide and authorization documentation. There's a basic outline of processing this flow in this blog post which may serve as a useful example.

The example in the blog uses curl but I need HTTP. I tried the online conversion tool from GitHub but it just gets syntax errors. I have my AppKey and AppSecret but what is the authorization code and do I need a redirect URI since I want the response to come right back to the HTTP request?

@Jeff B.63 wrote:
The example in the blog uses curl but I need HTTP. I tried the online conversion tool from GitHub but it just gets syntax errors. ...

Hi @Jeff B.63,

You can add -v option (verbose) in every curl command and you'll get entire HTTP request in the console output as is. 😉

@Jeff B.63 wrote:
... I have my AppKey and AppSecret but what is the authorization code and do I need a redirect URI since I want the response to come right back to the HTTP request?

Hope this helps.

I just tried the first step in your instructions and the browser returned an error "invalid client id".

Do I need to apply for production on the App or something?

@Jeff B.63 wrote:
...
Do I need to apply for production on the App or something?

No. Probably mistake in copy/paste.

I just tried too and everything works. Make sure you copy your client ID correct - even one symbol messed and... you saw the result. 🙋

Thanks @Здравко It was because I left the brackets in.

Worked perfectly, Thank you. do I now just use the refresh token as the access token in all of my http calls?

Authorization: Bearer <Refresh token>

@Jeff B.63 wrote:
Worked perfectly, Thank you. do I now just use the refresh token as the access token in all of my http calls?
Authorization: Bearer <Refresh token>

No, no, no,... definitely NO!

Refresh token doesn't replace access token, neither opposite! The refresh token is only used for refreshing (regenerating in fact) access token, nothing more. As I mentioned there (and as seems you skipped) in regular API calls valid access token (non expired - within the timespan as described) should be use. If needed (after currently used token expires), execute the last call in my description before next regular API call. 👆

Hope it's a bit more clear now.

Thank you for your help @Здравко, I read your other directions more clearly and it worked great.

My next challenge was how to use the refresh token in my Logic App. After an awful lot of searching, I was able to cobble something together.

For anyone else finding this thread, I will include that information for them below:

I had to set up blob storage in Azure and set any flows to use a system managed identity with the role of "Storage Blob Data Reader".
I then set up a new Logic App with a Recurrence Trigger set to 5 mins (or whatever you want) with the role of "Storage Blob Data Owner".
I added a file to the storage and use that same name throughout, say DBtoken.txt.
I retrieve the blob metadata and use a condition to check if utcNow() > (LastModified timestamp + 4 hrs).
False does nothing
True then runs an HTTP action using the refresh token to get a new 4hr token:
Then I save the blob back into the storage using the same filename as before - DBtoken.txt
Now any Logic Apps I want to have access to the Dropbox API can do so by reading the blob and getting the current access token. I'll describe that here:

Initialize a boolean variable called Token_Expiry
Retrieve the blob data from the blob storage
Insert an Until function that runs until Token_Expiry is = to True
Add a Condition inside the Until that check if utcNow() <= (Last Modified + 4hrs)
False does nothing
True has three actions: get blob content, parse json of blob content and sets Token_Expiry to True
Finally, right after the Until, I initialize a variable to hold the current token and use it in the HTTP Dropbox API actions I have later in the flow.

Maybe there is a simpler way to do this but this is all I could figure out with my very limited knowledge.

Hi @Jeff B.63,

Congratulations to you for your solution! 🙂 I believe your sharing will help many other people working on the same environment.

There are some imperfections though that push your solution to the border of stability. There is small but real chance some of your API calls to fail authentication! Of course in such a situation the details are important (something I don't know), but in all cases minimizing assumptions in the code is a good idea (they may play bad game 😈).

@Jeff B.63 wrote:
...
4. I retrieve the blob metadata and use a condition to check if utcNow() > (LastModified timestamp + 4 hrs).
...

When something is NOT guaranteed in any way better don't rely on! Yes, typically access token validity period is 4hr, but again typically NOT mandatory (may be less). I gave it just as example, nothing more. I mentioned in explicit way that validity is denoted in "expires_in" field. You're ignoring this value in favor of assumption! In addition it's good idea to "cut" 2, 3, or 5 mins out from validity period, cosa there are always some delays in token receiving, calculations, etc. - something that accumulates and can... make your check wrong (and you code tries work with just expired token in some cases).

@Jeff B.63 wrote:
...
7. Finally, right after the Until, I initialize a variable to hold the current token and use it in the HTTP Dropbox API actions I have later in the flow.
...

Hm...🤔 How long is this flow of actions? Is there any chance for your token expiration meantime? Important detail! It's good idea to check for token validity at the beginning of every API call, not at the beginning of flow of calls - just to make the things more secure. Even more in such a way you don't need additional trigger - the call, you're going to do, itself is a trigger. 😉

Good luck to you and all others interested.