I have made a hobby, non-profit, free app that aggregated Myanmar (my nationality) songs from SoundCloud and let my country-man listen more conveniently through my App.
And recently, I have discovered the "play" requests (/tracks/:id/stream) from my App is experiencing Reaching Rate Limit error from SoundCloud.
I know SoundCloud has 15K request limit per ClientID in a day. And my App only has about 10K total playbacks in a day.
I'm suspect that someone is using my ClientID and making **automated** "play" requests to SoundCloud. My question is - is there any way that I can trace the origins of my ClientID's "play" requests ?
Related
I have a Facebook Application in development mode that shows as having 3 daily_active_users. From my understanding of the Graph API documentation, I can make 200 * daily active users = total request per hour, thus, I should be able to make 600 requests per hour
I am then making a Test User and trying to create a page via the accounts endpoint:
https://developers.facebook.com/docs/graph-api/reference/user/accounts/#Creating
This goes well for a single request. I then tried to script this, with 2 second timeouts in between each request, and tried to create 100 pages. After about 10 requests, I get the following response from the Facebook API:
{"error":{"message":"We limit how often you can post, comment or do other things in a given amount of time in order to help protect the community from spam. You can try again later. Learn More","type":"OAuthException","code":368,"error_data":{"sentry_block_data":"...","help_center_id":0},"error_subcode":1390008,"error_user_msg":"","fbtrace_id":"..."}}.
It states that my request is being rejected due to hitting some kind of limit, but what is this limit? I can't find it in the documentation anywhere. Is there a limit to the number of pages I can create with a test user per hour/day?
When streaming a single track on Deezer from the server side, how can Deezer recognize that this track came from Flow radio and therefore give a full streaming url for a free user? I seem to always receive a 30 second preview for free users, which we would like to avoid.
For the api to know that the track is within the subset of of a radio station (vs an on demand track), the api call needs to include the id of the station from which it came:
https://api.deezer.com/streaming_url.php?access_token=xxxx&radio_id=yyy&track_id=zzz
rather than simply:
https://api.deezer.com/streaming_url.php?access_token=xxxx&track_id=zzz
I am building an app about joke telling using soundcloud api. So does soundcloud limit 15000 applied in 24 hour means all my app in in every device can applied for 15000 or one app in individual device?
Form Sound cloud developers portal
Effective July 1, all requests that result in access to a playable
stream are subject to a limit of 15,000 requests per any 24-hour time
window. Currently, this is inclusive of all requests that are made to
/tracks/:id/stream.
After a previous time window has expired, a new time window starts
from the first request made.
The majority of SoundCloud API rate limits are in the form of 24-hour
time windows.
For more details visit
https://developers.soundcloud.com/docs/api/rate-limits
I have an app for Android which checks for new notifications from Facebook every N minutes, where N is more than 5 minutes (default is 30 minutes). That app also makes some user-generated requests to Facebook's Graph API.
Recently (since the moment we added scheduled polling for new notifications), Facebook started to limit our app (with error #17 "User request limit reached" mostly, but sometimes it gives error #4 "Application request limit reached").
The Insights Dashboard gives us following statistics: 255,000 requests per day, 432 users. That gives roughly 590 requests per user per day, which is far from any mentioned limit for API I was able to find.
Facebook's information on rate limiting is really vague, here are some numbers you can usually find in different sources:
600 calls per 600 seconds per token per IP.
100M calls per day per app.
10,000 calls per user token per day.
The scheduled requests which our app does on a regular basis is a simple FQL:
SELECT sender_id,created_time,title_text FROM notification WHERE recipient_id=me() AND is_hidden = 0 AND is_unread = 1
Even with the minimal update interval of 5 minutes, it will be fired 288 times per day.
We tried to replace this request with Graph API call, but it didn't change a thing.
I know that there are other apps that have similar functionality and they seem to not have these limitations.
Does anybody know if there are any way to avoid being limited by Facebook with such reasonably low amount of calls?
Thanks!
It turned out that there was a nasty bug in the code which was really hard to reproduce, that sometimes forced the app to make API requests in a loop for 10-30 minutes in a row. Only a small percent of clients had that problem, but it was enough to bump into API limits.
It seems that FB API calculates limits based on the number of users of the app, so even with a rather limited amount of calls we had a rate limiting problem.
Another observation is that despite the fact that only a limited number of users were doing a lot of API calls, FB did limiting for all users.
Hope that information will be helpful somehow to resolve similar issues.
I am conducting test for a future project. I tried to rapidly post 100 - 200 test messages to a test user's feed from a server creating ~20 threads in parallel to send them as fast as possible. I got positive response to each one of those requests (including the id of the item being created in the body) but random number of those those messages does not appear on the facebook user's feed. For example it as ~40 when sending 200 in batch.
Any idea what could be causing this? It is weird especially considering that I am getting positive answer to each request.
Most likely Facebook spam detectors are filtering the messages after they get posted. Why would you possibly need to post 200 messages in a row to a users account? Your app would get shut down so fast. You can use the Facebook api to create a bunch of test accounts and then try distributing the posts to several different users to simulate real usage.