Implementation of URL statistics endpoint?


#1

So, I’ve done some searching of other discussions related to this topic, and it seems that using the undocumented endpoint http://urls.api.twitter.com/1/urls/count.json is not allowed outside of the context of the Tweet button. Are there any plans to add a new endpoint to retrieve this data? Or better yet a way to send multiple URLs in a single request and get back the total counts for each of them (and possibly even other data such as the re-tweet count)?

I’ve seen this comment, but it’s been well over a year since it was made, and there’s even been a new API version since then:
https://dev.twitter.com/discussions/5653#comment-14468

Clearly, other developers want an easy way to get this data (you’ve admitted so yourself), but it seems that the recommended (only?) way to do this is to use the streaming API with a url-encoded URL to pull tweets as they come through and count them “manually”. This seems like an extremely overly complex solution to something that should be trivially simple, and it will only provide data starting from when the stream was started (whereas the Tweet button count seems to be a grand total). Isn’t this actually creating more work, not just for the developer, but also for Twitter since you’re now having to stream a bunch of data rather than reply to a single HTTP request?

Facebook has exactly this kind of thing (https://developers.facebook.com/docs/reference/fql/link_stat), and it seems (at least from my perspective) like a relatively easy thing to implement since the data is already available for the Tweet button)

Here’s a use case:
Say I’m running a retail website, and I have 100 different individual product pages and I’m interested in seeing which ones of those are most popular on Twitter. How would I go about getting that data?

From my understanding, the suggested way would be to setup 100 different streams (which I would have to do at the point that the product page is created) in order to count up the number of Tweets coming in, and would have to leave those streams open indefinitely.

On the other hand, if I had an endpoint similar to http://urls.api.twitter.com/1/urls/count.json available to me, I could simply make 100 HTTP calls (or less, if it allowed me to send multiple URLs at once) just one time in order to get the total counts, and then be done with it.