nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

V2 API - error message format

tsumit g.

Hello! I'm trying to make requests to V2 API with incorrect details and I'm getting error messages of the following format. Also, added the CURL requests made to trigger the errors.

Please confirm if this format will stick around. Are there any links where this is documented?

curl -iX GET https://api.dropbox.com/2/team/get_1info

Unknown API function: "team/get_1info"

----------

curl -iX GET https://api.dropbox.com/2/team/get_info -H "Authorization: Bearer dsdf"

Error in call to API function "team/get_info": The given OAuth 2 access token is malformed.

-------

curl -iX GET https://api.dropbox.com/2/team/get_info -H "Authorization: Bearer "

Error in call to API function "team/get_info": Invalid authorization value in HTTP header "Authorization": "Bearer".  Expecting "Bearer <oauth2-access-token>".

----

curl -iX GET https://api.dropbox.com/2/team/get_info -H "Authorization1: Bearer "

Error in call to API function "team/get_info": Must provide HTTP header "Authorization" or URL parameter "authorization".

Also, is there any reason, why the response mimetype is `text/plain` instead of `application/json`?

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

Yes, all of the cases you shared result in a 400, as they don't follow the specification.

If you try a request with a token that might be valid, that is, it matches the expected pattern, but has been revoked, for example, you will get a 401:

$ curl -vX POST https://api.dropboxapi.com/2/users/get_current_account \
>     --header "Authorization: Bearer Zu9U1XOZl8QAAAAAAANVDUuVaEzgdX8UMaDoKneBbU-SCqZdaYwBTtWqY6103uGZ"

> POST /2/users/get_current_account HTTP/1.1
> Host: api.dropboxapi.com
> User-Agent: curl/7.42.1
> Accept: */*
> Authorization: Bearer Zu9U1XOZl8QAAAAAAANVDUuVaEzgdX8UMaDoKneBbU-SCqZdaYwBTtWqY6103uGZ

< HTTP/1.1 401 Unauthorized
< Server: nginx
< Date: Tue, 24 Jan 2017 18:30:51 GMT
< Content-Type: application/json
< Content-Length: 87
< Connection: keep-alive
< User-Agent:
< Www-Authenticate: Dropbox-API
< X-Dropbox-Request-Id: 8fdb89aaffd147eb489fa61ec0a5058a
<
* Connection #0 to host api.dropboxapi.com left intact
{"error_summary": "invalid_access_token/..", "error": {".tag": "invalid_access_token"}}

The other codes that are used for other scenarios are documented here:

https://www.dropbox.com/developers/documentation/http/documentation#error-handling

All comments

Greg-DB

Depending the type of error, the body with either contain a plain text error message, or a structured JSON error.

You can use the response's Content-Type header to determine the type of error and have your app handle it accordingly.

We don't have any plans to change how this works. You can find information on the high level errors here:

https://www.dropbox.com/developers/documentation/http/documentation#error-handling

tsumit g.

Thanks Greg. In all the cases for which I posted the request and errors, the only status code received was 400. Per the link you provided, 401 is the appropriate code for Bad/expired tokens.

Is there a way we could use the specific 4xx codes when it's clearly defined as to what went wrong? 401 for any Authorization errors (bad/expired/malformed token, missing token, missing Authorization header), 404 for URL not found cases, etc.,

400 is more of an umbrella that caters to errors specific to the payload. And reading from response payload should be necessary only if the request payload didn't conform to the server requirements. We don't need to parse the payload to find out the request was unauthorized or the endpoint was not found.

Greg-DB

Yes, all of the cases you shared result in a 400, as they don't follow the specification.

If you try a request with a token that might be valid, that is, it matches the expected pattern, but has been revoked, for example, you will get a 401:

$ curl -vX POST https://api.dropboxapi.com/2/users/get_current_account \
>     --header "Authorization: Bearer Zu9U1XOZl8QAAAAAAANVDUuVaEzgdX8UMaDoKneBbU-SCqZdaYwBTtWqY6103uGZ"

> POST /2/users/get_current_account HTTP/1.1
> Host: api.dropboxapi.com
> User-Agent: curl/7.42.1
> Accept: */*
> Authorization: Bearer Zu9U1XOZl8QAAAAAAANVDUuVaEzgdX8UMaDoKneBbU-SCqZdaYwBTtWqY6103uGZ

< HTTP/1.1 401 Unauthorized
< Server: nginx
< Date: Tue, 24 Jan 2017 18:30:51 GMT
< Content-Type: application/json
< Content-Length: 87
< Connection: keep-alive
< User-Agent:
< Www-Authenticate: Dropbox-API
< X-Dropbox-Request-Id: 8fdb89aaffd147eb489fa61ec0a5058a
<
* Connection #0 to host api.dropboxapi.com left intact
{"error_summary": "invalid_access_token/..", "error": {".tag": "invalid_access_token"}}

The other codes that are used for other scenarios are documented here:

https://www.dropbox.com/developers/documentation/http/documentation#error-handling

tsumit g.

Thanks Greg, you're right. But I still feel it shouldn't matter how the token is or what form it is. If the authorization has failed due to any reason, throw a 401 status. At the end of the day, the user is deemed to be unauthorized to access the resource.

However, the response payload could be elaborate and say what exactly failed or was missing. Let me know if this is acceptable.