We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
API get_metadata returns 429 text/html
Recently we've been getting text/html 429 responses from the get_metadata endpoint, when we specify
Accept: application/json
header.
Response:
{:request=>{:url=>"https://api.dropboxapi.com/2/", :endpoint=>"files/get_metadata", :body=>"{\"path\":\"/myfolder\",\"include_deleted\":true}"},
:response=>{:code=>429, :body=>"<!DOCTYPE html>\n<html>\n<head><meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\">\n<title>Dropbox - 4xx</title>\n<link href=\"https://cfl.dropboxstatic.com/static/css/error.css\" rel=\"stylesheet\" type=\"text/css\"/>\n<link rel=\"shortcut icon\" href=\"https://cfl.dropboxstatic.com/static/images/favicon.ico\"/>\n\n</head>\n<body>\n<div class=\"figure\">\n<img src=\"https://cfl.dropboxstatic.com/static/images/illustration_catalog/404_error-illo.png\" srcset=\"https://cfl.dropboxstatic.com/static/images/illustration_catalog/404_error-illo@2x.png 2x\" alt=\"Error: 4xx\"/>\n</div>\n<div id=\"errorbox\">\n<div class=\"not-found\"> <h1>Error (4xx)</h1> We can't find the page you're looking for. <div class=\"not-found--links\"> Here are a few links that may be helpful: <ul> <li><a href=\"https://www.dropbox.com/home?_tk=fof\">Home</a></li> <li><a href=\"https://www.dropbox.com/help?_tk=fof\">Help center</a></li> <li><a href=\"https://www.dropbox.com/login?_tk=fof\">Sign in</a></li> <li><a href=\"https://www.dropbox.com/register?_tk=fof\">Get a free account</a></li> <li><a href=\"https://www.dropbox.com/plus?_tk=fof\">Dropbox Plus</a></li> <li><a href=\"https://www.dropbox.com/business?_tk=fof\">Dropbox Business</a></li> </ul> </div> </div>\n</div>\n\n<script>\nmessage = {\"ru\": \"\\u003cdiv class=\\\"not-found\\\"\\u003e \\u003ch1...
Is there a reason why we're getting a text/html response instead of a json response?
To follow up here, the team confirmed that they found and resolved the issue with the excessive 429 responses with HTML bodies as of late Friday. Apologies for the inconvenience.
- Greg-DB
Dropbox Staff
Thanks for the report. It looks like we may be using a generic HTML error page in some rate limiting cases. We'll look into it.
Thanks, keep me posted please!
We're having the same issue. Suddenly some of our internal applications are crashing due to this. It disrupts our work very seriously. I dont feel me made any abusive calls.
Our apps are set in "development" status and used only by ourselves.
We're having a similar issue.
Some requests to different endpoints are returning 429, that's may be normal due to rate limit.But before, Retry-After header was returned, and we waited that time before retrying another request.
Now, Retry-After isn't present and we don't know exactly how long to wait before retrying or continuing the upload.
- Greg-DB
To follow up here, the team confirmed that they found and resolved the issue with the excessive 429 responses with HTML bodies as of late Friday. Apologies for the inconvenience.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
