Our implementation here is less than optimal at the moment during the transition from basic auth to OAuth.
At least as it currently stands, you should think of API methods that "require authentication" to mean "requires an access token" with OAuth. In Basic Auth, it meant that you needed to provide a user and password with the request. If the API method "doesn't require authentication" that means that you don't need an access token to complete the request. Today, Twitter doesn't support two-legged OAuth, which would be the means that your application could identify itself to Twitter and make requests without an access token. This would be the most appropriate way for Twitter to handle calls that are essentially consumer-to-service-provider without a user. Without two-legged OAuth support at Twitter yet, your best bet might be to not use authentication at all when accessing resources that don't require auth -- meaning, you just do simple REST calls without identifying yourself with any OAuth parameters, basic auth, or otherwise (though a User-Agent is always appreciated). Your requests would then be applied to the general whitelist yielded solely to a requesting IP address. Long-term, the right thing for Twitter to do here is support two-legged OAuth. When your application is doing something that doesn't involve a user in some way, you'd sign your requests and identify yourself as your application while accessing the resource, but would not be supplying an access token. In this scenario, all API requests, whether they require authentication by a member or not, would require application-level authorization. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Thu, May 20, 2010 at 1:20 AM, ALSPL <ritikasan...@gmail.com> wrote: > Our app authenticates users with Twitter (using oAuth) and then sends > API calls like > 1. users show > 2. status friends > > These calls do NOT require authentication but we want them to count > against user's limit --> so it goes to 150/hr on users quota and NOT > the app quota. > > However, even after making sure that the user is authenticated, these > are not deducting the user's limit. > curl -u user:password > http://api.twitter.com/1/account/rate_limit_status.xml > gives the same number - it does not get deducted. > > It seems that they are still getting counted in the app quota of 150/ > hr. > > Q1. How do we check if the app quota is getting deducted? > Q2. How do we create/make the api calls so that they count against the > user's quota? > > Thanks >