We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
Requests always fail from deployed website, but work fine in localhost
I'm using the SDK for requests from my Next.js website. Everything works fine in localhost, but as soon as it is deployed on Vercel, I can only get 400 Errors for my requests to the API. See the ...
Thank you for this additional guidance.
I could not make it work at first, but found a solution. For anyone else, new to making this kind of API calls and relying too much on abstracted calls with the SDK (like me), the data needs to be encoded before being passed to the body.
const data = { grant_type: 'refresh_token', refresh_token: refreshToken, client_id: clientId, client_secret: clientSecret, }; const response = await fetch(`https://api.dropboxapi.com/oauth2/token`, { method: 'POST', headers: { 'content-type': 'application/x-www-form-urlencoded', }, // Note this: the data needs to be encoded first! body: new URLSearchParams(data), }); console.log(await response.json());Thanks again for your concern and patience!
Greg-DB
Dropbox Staff
Dropbox StaffI see you're supplying a refresh token, app key, and app secret to the Dropbox JavaScript SDK. In that case, the SDK should automatically use those to retrieve a new short-lived access token (the string that starts with "sl.") whenever needed, which it would then use to perform Dropbox API calls (such as usersGetSpaceUsage).
As you pointed out, in the failing case it appears to be lacking an access token.
In the last screenshot you provided, I see what appears to be the call to use the refresh token to get an access token (with the 'grant_type' and 'refresh_token' parameters), however it looks like it's being made to your app's "/admin/dashboard" path, instead of the Dropbox token endpoint "https://api.dropboxapi.com/oauth2/token" as is necessary to receive the access token from Dropbox.
It's not clear why that is using the wrong URL though. It is technically possible to change the domain (relevant code here and here, meant for internal testing), but that should only change the domain and not the path. From the code you shared though, I don't see you changing that setting anyway. Is the code posted on GitHub exactly what is being run the failing case? Otherwise, is there anything on that environment that would be rewriting requests?
Hi Greg. Thanks a lot for taking the time to help me.
The code in the repository is the exact one being used for the deployment (with Vercel), and as you could see I'm using a minimal setup. The only other API requests I'm using are made through Google Drive and Auth0 endpoints.
There is one thing I could think of, but I'm uncertain if it's relevant. Some pages are protected, and can only be accessed if the user is connected. And /admin/dashboard is one of them.
Therefore, navigating to this page, while not being connected, redirects to the Auth0 authentification page AUTH0_ISSUER_BASE_URL. On successful login, the user is sent back to the page.
However, I've just tried making that page public again. It does not solve the issue, though I'm getting a different error, similar to what you've seen on the Vercel screenshot:
So it does make the issue a bit more specific. It looks like I should find out why these requests are not made to the Dropbox API url, though they are on localhost, and how to fix it.
I will try tweaking that domain tomorrow in the morning, it's getting late already here. Maybe I can get it back to the original one, though I did not change it. And I'll try to completely remove other libraries to isolate the problem.
Thanks again for your help! I'll keep you updated, if I were to find any lead!
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
