Tweet/retweet urls


#1

Hi All,

I am building an Intranet Application which interacts with Twitter. The issues is that the entire application and its users are behind one IP address so they will be subjected to a rate restriction? To avoid that, I am making a Webservice which interacts with Twitter , gets the tweets and caches it and then sends the response to my application. But, due to rate limiting the ability of my application to interact with Twitter is hindered.So, I am trying to use the below links to do the same.

https://twitter.com/intent/tweet?in_reply_to=(tweetId)

https://twitter.com/intent/retweet?tweet_id=(tweetId)

https://twitter.com/intent/favorite?tweet_id=(tweetId)

I wanted to know their validity, would they be used by twitter or would they expire in the future. One more thing ,any feedback about my implementation would be helpful.

Thanks and Regards,
Neil


#2
  • Those “intents” URLs are part of a supported API call Web Intents – they’ll be around for quite awhile. [node:183]
  • API v1.1 doesn’t consider IP address as part of its rate limiting scenarios. Each of your users would authorize your application to act on their behalf, and the actions they take within your application are “partitioned” as far as rate limiting is concern – each user has their own personal rate limit. See [node:10066].
  • The idea of centralizing your collection and cache of Tweets is a good one – I recommend using a Streaming API to collect tweets whenever possible.
  • Using web intents to offer interactivity is a great, simple solution.

#3

Hi

Thanks for that. Some more questions.

So basically the application is rate limited? I have user a, and user b linked to app 'me ’ .

Suppose app ‘me’ get tweets from a store it somewhere n display it on a page. Then user b logins to the app and views tweets via the app in the page. My question is can user b then replies or retweeets on user a tweets?

The rate limiting ex 300 requests per window applies to the application or the access token? I m asking this as one application can interact with many users and generate many access tokens. So is it based on app or access token?

Could you please help me with this


#4

Could someone please help me with this?


#5

There are really three kinds of rate limiting on Twitter – one of which we don’t call rate limiting.

First: user-based allowances for write actions – these have nothing to do with applications. Users can tweet, retweet, reply, DM, follow, favorite and all of that stuff. The user intrinsically has an allowance to how often they can do that. How many times they can tweet or DM “right now” isn’t a value exposed by the API at all. An application won’t know that a user doesn’t have any more allowance for tweeting or replying or retweeting until they attempt the action action.

The second and third kind of rate limiting are API rate limits. They only apply to read actions and each possible read action has it own limit divided from other read methods.

Second: app-only auth rate limiting – this is where you’re explicitly using a form of authentication that does not involve an end user. For each API method that you call, your application is allowed a certain amount of requests (different for each method) per 15 minutes in this context. The rate limiting here is conservative and meant to be used for very simple use cases or as an additional reserve for…

Third: user-based rate limiting – this is where you’re using OAuth 1.0A and access tokens representing your users. Just like app-only auth, each possible read method has its own rate limit associated with it. This rate limit applies in 15 minute windows and is unique for each access token you have representing your end-users.


#6