cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to know what we learned at IBC? Check out our learnings on media, remote working and more right here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Using API in Salesforce with Named and External Credentials and OAuth2 upload OK but call to file sh

Using API in Salesforce with Named and External Credentials and OAuth2 upload OK but call to file sh

bossgolfer
Explorer | Level 4

I have setup OAuth2 in Salesforce along with Named Credentials and External Credentials.  I am calling the File Upload API in the code..that works fine with all the above. I setup a second Named Credential that uses the shared External Credentials that the Upload API uses. The only real reason for this is the accomodate the different endpoints (why does Dropbox do this?). The Post to the Set Sharing /2/sharing/create_shared_link_with_settings endpoint uses the NamedCredential and gets a new/different bearer token. BUT, when that call is posted I get a 401 Unauthorized. 

The response says: 

{"error":{".tag":"missing_scope","required_scope":"sharing.write"},"error_summary":"missing_scope/"}

The APP I defined in DROPBOX has sharing.write...so a little confuse. Where can I pass in that scope? 

 

Should I just generate a token in the APP for the one user...is that a permanent token that just replaces creds?

UPDATE: I did use the APPTOKEN and that seems a better approach and calling OAuth each time. 

Its working, but now I have to figure out how to chunk load larger files. UGH

 

Thoughts? Is there any reason getting a second token on a second HTTP callout is a problem when calling the different API?

3 Replies 3

DB-Des
Dropbox Engineer

Hi @bossgolfer,

 

A 'missing_scope' error indicates that while the app may be permitted to use that scope, the particular access token you're using to make the API call does not have that scope granted. Also, be aware that just adding a scope to your app via the App Console does not retroactively grant that scope to existing access tokens or refresh tokens.

 

That being the case, to make any API calls that require that scope, you will need to re-authorize the app to get a new access token (and refresh token, if being used) with that scope.

 

Alternatively, apps can request different scopes, per authorization, using the scope parameter in the Authorization URL. Doing this would grant the scope(s) set in the URL to the resulting token only — it would not update the app's pre-set permissions, nor would it affect any other tokens.

 

Additionally, we would recommend you confirm that the client_id of the app, with the sharing.write permission enabled, is the one being used in the Authorization URL.

 

You can refer to the OAuth Guide and authorization documentation for more information.

 

To answer your additional questions:

1. The access token generated in the app is not permanent, it does expire.

2. Could you expand on what blocks you may be encountering as far as wanting to "chunk load larger files"?

3. Could you also further explain what you mean by "getting a second token on a second HTTP callout is a problem when calling the different API"?

bossgolfer
Explorer | Level 4

To answer your additional questions:

1. The access token generated in the app is not permanent, it does expire.

 

2. Could you expand on what blocks you may be encountering as far as wanting to "chunk load larger files"?

>>> I actually got that working OK.

 

3. Could you also further explain what you mean by "getting a second token on a second HTTP callout is a problem when calling the different API"?

Its just not clear to me what was causing the missing scope on the sharing call after the initial call to file upload. 

 

So do you recommend going back the the Oauth access vs the token.

DB-Des
Dropbox Engineer

@bossgolfer, It is recommended to get an access token via an OAuth flow, yes.

 

Keep in mind that access tokens, whether obtained from the app within the App Console or via OAuth flow, will eventually expire. The expiration time can be confirmed in the property expires_in, which is found in the response object returned from the /oauth2/token endpoint.

 

I hope this information provides more clarity!

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    DB-Des Dropbox Engineer
  • User avatar
    bossgolfer Explorer | Level 4
What do Dropbox user levels mean?