This endpoint on Spotify's Web Api throws a 500 error for the username "spotify":
GET https://api.spotify.com/v1/users/{user_id}/playlists
Is this intentional on Spotify's end? Does Spotify not wants developers to access its playlists.
Note - All other usernames work fine
A 500 error should always be treated as being unintentional. If the server side wants to limit access a response code in the 400 range should be used instead, like 403 or possibly 401. It is likely that there are so many different public playlists for the Spotify account that one of them has triggered a bug. If for some reason the error code 500 is intentional, it is still a bug, but in the API, which should be fixed.
I work at Spotify, but don't have direct access to this system. I will let people know.
Related
I use the version 9.0 of the Grapph API. The leads retrieval was wroking ok, but the last 3 weeks I am not able to retrieve lead form information, using the endpoint :
https://graph.facebook.com/v9.0/${leadId}/?access_token=${process.env.FACEBOOK_PAGE_ACCESS_TOKEN}
The page access token as well as the facebook app has all the permissions like leads_retrieval, pages_manage_ads, pages_manage_metadata, pages_read_engagement, business_management, public_profile, pages_show_list.
When I create a lead form id from the page that is connected to the app, and then use the testing tool (https://developers.facebook.com/tools/lead-ads-testing) to check if the webhook works, everything works ok !!
The facebook and the connected page that are connected and were used for testing purposes, do belong in different businesses.
The problem is that when someone submits a lead from paid campaigs, then the following error message shows:
An invalid response was received from the Facebook API: {"error":{"message":"Unsupported get request. Object with ID '1223289864932223' does not exist, cannot be loaded due to missing permissions, or does not support this operation. Please read the Graph API documentation at https://developers.facebook.com/docs/graph-api","type":"GraphMethodException","code":100,"error_subcode":33,"fbtrace_id":"AIQ5Q-yJo249IZwdn10dfhi"}}
Is there an error in the set up of the whole system? Something that needs to be changed? Why suddenly did it stop working ?
I consistently get this response
{ error: { status: 500, message: 'Server error.' } }
when I try to retrieve all playlists for my user using this endpoint
GET https://api.spotify.com/v1/users/{user_id}/playlist
I am doing this repeatedly as a test case while I develop the plumbing for my Spotify web api application.
Sometimes it fails when I start at offset 0. Sometimes it succeeds at offset 0 (and offset 50, 100, 150, etc.) and fails later. I have about 900 playlists.
It fails whether I get 20 playlists at a time or the maximum of 50.
I see nothing unusual in the response headers.
Is this a bug on the Spotify's end? I assume since I'm getting status 500 that this is not related to hitting a request rate limit of some kind, or some error in my request.
I would appreciate any insight anyone has to offer.
Responses with status code 500 from the /v1/users/{user_id}/playlists/ endpoint can be caused by a number of reasons, none of which is your application's fault. There are cases where a user's list of playlists (or an individual playlist) cause temporary issues in Spotify's backend. This occurs more often if the list of playlists have a lot of revisions, e.g. the user has an unusually large amount of playlists and have removed, added and moved them around a lot. We're working on resolving this but meanwhile we ask you to try again.
This isn't related to any of the query parameters sent in the request, it's simply an intermittent error.
Is this a bug on the Spotify's end? I assume since I'm getting status 500 that this is not related to hitting a request rate limit of some kind, or some error in my request.
Spotify's Web API return a response with status code 429 if the request has been rate limited. A list of which status codes are returned from the Web API can be found in the User Guide.
Since 3 or 4 days ago i'm not able to like any photos from any token, I think they blocked me to like. I still can follow/unfollow users via my application. I also can like photos via instagram iOS app.
This is the error i have:
"meta": {
"error_type":"APINotAllowedError",
"code": 400,
"error_message":"you cannot like this media"}
Do you know if they will unlock me or it's permanently?
Instagram changed the terms for using POST and DELETE requests. You can read more about it here http://developers.instagram.com/post/116410697261/publishing-guidelines-and-signed-requests
If you want to request access to those endpoints you can do it here, if your app is qualified.
https://www.facebook.com/help/instagram/contact/185819881608116#=
See API Terms of Use:
Do not abuse the API. Too many requests too quickly will get your access turned off
Wait for some days and see if they will free you... If you are still having trouble, i would suggest to create a new client and see what happens.
I am building a web application using the Spotify Web API. The calls are pretty straight forward and I don't understand if it is me doing something wrong, or if there is something wrong with the Spotify service.
I implemented the lookup call (works fine) and then add track IDs to my database when a button is clicked next to one of the results. I then do an ajax call to display that track in the "Play Button" iframe.
Instead of showing my playlist now, I very often get a 502 Bad Gateway error. (This error also appears on the Spotify website where the example is supposed to be shown.)
Is this something I cause? My browser / system causes?
Thanks a lot in advance!
(This error also appears on the Spotify website where the example is supposed to be shown.)
This suggests that the problem is on Spotify's side, assuming you're giving the Play Button a valid Spotify URI. Hang tight for a while and it should sort itself out.
My server returns a 403 forbidden error when a user tries to access a resource that they do not have access to. Along with the header the server also writes a small message describing the error.
In Firefox the error message gets displayed nicely and the user knows what's going on.
In Internet Explorer the message is hidden and replaced with the 403 Forbidden standard error page.
Are there any specific rules that allow me to display an error message across all browsers while still setting the status to 403 Forbidden?
Here is the RFC info on this status:
The server understood the request, but
is refusing to fulfill it.
Authorization will not help and the
request SHOULD NOT be repeated. If the
request method was not HEAD and the
server wishes to make public why the
request has not been fulfilled, it
SHOULD describe the reason for the
refusal in the entity. If the server
does not wish to make this information
available to the client, the status
code 404 (Not Found) can be used
instead.
It seems like I should be setting a message but IE just won't display it.
Try making your 403 page larger (i.e. more bytes). Some browsers assume that a short error page is the default page from the web server and decide to show their own, presumably more helpful text.
More info.
The implementation of error handling is browser dependent. In HTTP if you are just going to return a 403 error then you have to rely on the user agent (the technical name for the browser, the recipient of your error message may not be a browser) to handle out how it sees fit.
If you don't like how the browsers are handling 403 errors and want to ensure a consistent user experience across all browsers then redirect the user to your own 'permission denied' page. You can build a page that can explain to them why permission was denied and what they might be able to do about it. And it will be consistent for any browser.