Re: How to find out how many API requests have been used?
We do limit the number of updates a client can send over a period time to prevent spammers. That time period may change, and the number of updates one can post is much higher than most uses would dictate, but if you really need to be posting that frequently, please apply for whitelisting to lift the limit: http://twitter.com/help/request_whitelisting. On Wed, Dec 3, 2008 at 18:17, maximz2005 [EMAIL PROTECTED] wrote: Today, I've increased the time interval to two minutes, and so far, I think it's working without problems with posting. I've just set the interval to 1 minute, do you think it will give me posting problems? On Dec 2, 10:13 pm, maximz2005 [EMAIL PROTECTED] wrote: So if I increased this time interval to a minute or two, do you think posting would work? Thanks, -maximz2005 On Dec 1, 8:57 pm, Cameron Kaiser [EMAIL PROTECTED] wrote: Do you by any chance know whether updatingstatuscounts against the rate limit? It does not. I wrote a little test program for playing around with the API, that simply posts the time as astatusmessageevery 30 seconds. Sometimes, when I go online and check thestatusmessages, they stop abruptly, but the client doesn't give me a 404 error. Is this evidence of reaching the limit? No, it just means it wasn't posted. However, a test like that being posted out every 30 seconds over and over could be construed as a runaway bot to be filtered. You might not want to constantly update that frequently. -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems [EMAIL PROTECTED] -- I like my women like my coffee: weak, cold and bitter. -- Kevin Metcalf -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: 400 Error - Friendships Create Not Working
You've probably hit the rate limit. Check out the informative error message returned in the response body. On Thu, Dec 4, 2008 at 06:40, mattyp [EMAIL PROTECTED] wrote: Can anyone verify that the following works? http://twitter.com/friendships/create/bob.json?follow=true I just get a HTTP 400 Bad Request Thanks. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: A general status update from Twitter's API Team
Hi Alex, Thanks for the updates - one of the things I noticed is that the archive API method was marked as wontfix. I was wondering what this means for the future of accessing our Twitter history? Is this just something where we won't be able to export it in one shot, but still have access to the history through successive API calls? Thanks, dacort On Dec 2, 12:27 pm, Alex Payne [EMAIL PROTECTED] wrote: Hi all, Just wanted to give you an update on what's going on Twitter API land. Firstly, my colleague on the API Team, Matt Sanford (@mzsanford), is in town from Seattle and working from the Twitter offices. We're trying to make the most of this in-person time to clear out administrivia and plan the next several weeks of work. We've just finished cleaning up the list of API issues and enhancement requests (http://code.google.com/p/twitter-api/issues/list). We've closed, updated, re-prioritized, and generally attended to all tickets in the system. We have a number of fixes that are waiting on other parts of the Twitter engineering team to ship, and we've tried to clearly note which tickets aren't going to be dealt with until the next major release of the API. Just yesterday, Matt finished working with our Operations team to move Twitter Search to Twitter's data center. The Search API should now return results more quickly, and we believe that we've increased our queries per second (QPS) capacity as well. Additionally, Matt has been working with our User Experience (UX) team on a beta of OAuth support. The UX component of this work is almost complete, and we should be ready for our first deploy in the next week or ten days. The only potential blocker to this launch is the database schema changes it entails, which may be delayed by our Operations team as part of a broader set of database work. Having completed performance tests to our satisfaction, a colleague of ours has been testing our HTTP-based firehose solution for correctness and stability. So far he's uncovered no issues, and we should be starting a beta period with this service in a matter of days. Apologies for not having the beta going by Thanksgiving, but hopefully this additional testing will mean fewer issues and a reduced time-to-production. Our next major priority remains the rewrite of the Twitter API, which encompasses a variety of backend and frontend changes. We were hoping to have much of this work completed by the end of the year, and while I believe it'll be underway, I don't expect that it will be complete until early next year. If you have any questions about our priorities and projects, please let us know. Thanks! -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: A general status update from Twitter's API Team
Yup, until some other under-the-hood stuff changes, we can't really hand out a user's archive in a single request/response in a timely and database-friendly fashion. You'll still have to page through to get a user's full archive, but with effectively non-existent rate limits, this should be much easier. On Thu, Dec 4, 2008 at 12:01, Damon C [EMAIL PROTECTED] wrote: Hi Alex, Thanks for the updates - one of the things I noticed is that the archive API method was marked as wontfix. I was wondering what this means for the future of accessing our Twitter history? Is this just something where we won't be able to export it in one shot, but still have access to the history through successive API calls? Thanks, dacort On Dec 2, 12:27 pm, Alex Payne [EMAIL PROTECTED] wrote: Hi all, Just wanted to give you an update on what's going on Twitter API land. Firstly, my colleague on the API Team, Matt Sanford (@mzsanford), is in town from Seattle and working from the Twitter offices. We're trying to make the most of this in-person time to clear out administrivia and plan the next several weeks of work. We've just finished cleaning up the list of API issues and enhancement requests (http://code.google.com/p/twitter-api/issues/list). We've closed, updated, re-prioritized, and generally attended to all tickets in the system. We have a number of fixes that are waiting on other parts of the Twitter engineering team to ship, and we've tried to clearly note which tickets aren't going to be dealt with until the next major release of the API. Just yesterday, Matt finished working with our Operations team to move Twitter Search to Twitter's data center. The Search API should now return results more quickly, and we believe that we've increased our queries per second (QPS) capacity as well. Additionally, Matt has been working with our User Experience (UX) team on a beta of OAuth support. The UX component of this work is almost complete, and we should be ready for our first deploy in the next week or ten days. The only potential blocker to this launch is the database schema changes it entails, which may be delayed by our Operations team as part of a broader set of database work. Having completed performance tests to our satisfaction, a colleague of ours has been testing our HTTP-based firehose solution for correctness and stability. So far he's uncovered no issues, and we should be starting a beta period with this service in a matter of days. Apologies for not having the beta going by Thanksgiving, but hopefully this additional testing will mean fewer issues and a reduced time-to-production. Our next major priority remains the rewrite of the Twitter API, which encompasses a variety of backend and frontend changes. We were hoping to have much of this work completed by the end of the year, and while I believe it'll be underway, I don't expect that it will be complete until early next year. If you have any questions about our priorities and projects, please let us know. Thanks! -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: Why is authentication required to get follower info?
On Nov 21, 6:41 pm, Alex Payne [EMAIL PROTECTED] wrote: Please see the documentation athttp://apiwiki.twitter.com/REST+API+Documentation. You need to provide HTTP Basic Auth credentials when requesting thefollowersof another user. But why? Amir On Fri, Nov 21, 2008 at 15:31, Amir Michail [EMAIL PROTECTED] wrote: Hi, curlhttp://twitter.com/statuses/followers/amichail.rss yields ?xml version=1.0 encoding=UTF-8? hash request/statuses/followers/amichail.rss/request errorCould not authenticate you./error /hash Amir -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: Search API feature request: follows:username
On Dec 4, 12:44 pm, Matthew [EMAIL PROTECTED] wrote: You could implement this in the following way. 1. get all the follows of techcrunch 2. search for the keyword you want, saying from: username1 OR username2 OR ... usernameN Unfortunately that sort of query can be very slow even with only a few from:'s. Amir an example http://search.twitter.com/search?q=github+from%3Alebreeze+OR+matthewrudy shows all the tweets about github from myself and my friend Levent. Although with 32000 usernames I imagine it wont be fast, and you'd have to iterate over 320 requests to /statuses/followers.xml in order to grab all their usernames.
Re: Why is authentication required to get follower info?
On Thu, Dec 4, 2008 at 3:30 PM, Amir Michail [EMAIL PROTECTED] wrote: On Nov 21, 6:41 pm, Alex Payne [EMAIL PROTECTED] wrote: Please see the documentation athttp:// apiwiki.twitter.com/REST+API+Documentation. You need to provide HTTP Basic Auth credentials when requesting thefollowersof another user. But why? Amir I'm guessing because this mimics the behavior of the twitter website itself. You cannot see another person's followers-list without being logged into your account first. My $0.02, -Chad On Fri, Nov 21, 2008 at 15:31, Amir Michail [EMAIL PROTECTED] wrote: Hi, curlhttp://twitter.com/statuses/followers/amichail.rss yields ?xml version=1.0 encoding=UTF-8? hash request/statuses/followers/amichail.rss/request errorCould not authenticate you./error /hash Amir -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: Why is authentication required to get follower info?
Yup! On Thu, Dec 4, 2008 at 12:39, Chad Etzel [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 3:30 PM, Amir Michail [EMAIL PROTECTED] wrote: On Nov 21, 6:41 pm, Alex Payne [EMAIL PROTECTED] wrote: Please see the documentation athttp://apiwiki.twitter.com/REST+API+Documentation. You need to provide HTTP Basic Auth credentials when requesting thefollowersof another user. But why? Amir I'm guessing because this mimics the behavior of the twitter website itself. You cannot see another person's followers-list without being logged into your account first. My $0.02, -Chad On Fri, Nov 21, 2008 at 15:31, Amir Michail [EMAIL PROTECTED] wrote: Hi, curlhttp://twitter.com/statuses/followers/amichail.rss yields ?xml version=1.0 encoding=UTF-8? hash request/statuses/followers/amichail.rss/request errorCould not authenticate you./error /hash Amir -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: INCOMPATIBILITY ALERT: response body of /account/verify_credentials changing Dec 10th
I agree, this is a great change. On Dec 3, 11:07 pm, dean.j.robinson [EMAIL PROTECTED] wrote: return the representation of the authenticated user does that mean that the response will be the same as if we calledhttp://twitter.com/users/show/id.format for the authenticated user? If so that would be awesome and means I could completely eliminate some of the extra api calls that I'm making. Doesn't matter too much either way though, since both Hahlo 3.1 and Hahlo 4 (which I've recently begun work on) both currently use the http status for confirmation. thanks for the heads up. On Dec 3, 1:14 pm, Alex Payne [EMAIL PROTECTED] wrote: As perhttp://code.google.com/p/twitter-api/issues/detail?id=173we'll be changing the /account/verify_credentials method to return the representation of the authenticated user. Because some applications depend on the contents of this response, we're delaying this change until December 10th, 2008. Please update your applications to verify by response code, not by the response body for this method. If you get a 200 back, you're verified. If you get a 401 back, you're not. If you can't ship an update in 8 days, please let us know and we'll push the date out further. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: Why is authentication required to get follower info?
On Dec 4, 3:46 pm, Alex Payne [EMAIL PROTECTED] wrote: Yup! But why? Is this done to encourage more people to sign up? Amir On Thu, Dec 4, 2008 at 12:39, Chad Etzel [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 3:30 PM, Amir Michail [EMAIL PROTECTED] wrote: On Nov 21, 6:41 pm, Alex Payne [EMAIL PROTECTED] wrote: Please see the documentation athttp://apiwiki.twitter.com/REST+API+Documentation. You need to provide HTTP Basic Auth credentials when requesting thefollowersof another user. But why? Amir I'm guessing because this mimics the behavior of the twitter website itself. You cannot see another person's followers-list without being logged into your account first. My $0.02, -Chad On Fri, Nov 21, 2008 at 15:31, Amir Michail [EMAIL PROTECTED] wrote: Hi, curlhttp://twitter.com/statuses/followers/amichail.rss yields ?xml version=1.0 encoding=UTF-8? hash request/statuses/followers/amichail.rss/request errorCould not authenticate you./error /hash Amir -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: Why is authentication required to get follower info?
I'll admit, I'm curious about this myself. Another example is authenticating to pull a user's friends feed. With the exception of protected users, why not allow that public information to be pulled out via the API? -Original Message- From: Amir Michail [EMAIL PROTECTED] Date: Thu, 4 Dec 2008 15:23:04 To: Twitter Development Talktwitter-development-talk@googlegroups.com Subject: Re: Why is authentication required to get follower info? On Dec 4, 3:46 pm, Alex Payne [EMAIL PROTECTED] wrote: Yup! But why? Is this done to encourage more people to sign up? Amir On Thu, Dec 4, 2008 at 12:39, Chad Etzel [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 3:30 PM, Amir Michail [EMAIL PROTECTED] wrote: On Nov 21, 6:41 pm, Alex Payne [EMAIL PROTECTED] wrote: Please see the documentation athttp://apiwiki.twitter.com/REST+API+Documentation. You need to provide HTTP Basic Auth credentials when requesting thefollowersof another user. But why? Amir I'm guessing because this mimics the behavior of the twitter website itself. You cannot see another person's followers-list without being logged into your account first. My $0.02, -Chad On Fri, Nov 21, 2008 at 15:31, Amir Michail [EMAIL PROTECTED] wrote: Hi, curlhttp://twitter.com/statuses/followers/amichail.rss yields ?xml version=1.0 encoding=UTF-8? hash request/statuses/followers/amichail.rss/request errorCould not authenticate you./error /hash Amir -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: Search API feature request: follows:username
On Dec 4, 8:32 pm, Chad Etzel [EMAIL PROTECTED] wrote: Not really an elegant solution/implementation, but I could imagine that the database query needed to the equivalent on the back-end servers would not exactly be trivial either. Yeah. I imagine the search functionality is actually done using lucene, and some sort of facets? Or at least it'd make sense given the nature of the search, and the fact that the query language looks like lucene syntax. Not that I've worked with such big fulltext searching, but our search of 30,000 jobs is incredibly slow once you start adding criteria (especially range queries). With twitters one billion messages I'm sure the game changes quite a lot.
Re: since_id limit
No, just use the count (200) parameter if you want all tweets since that id. -- Swap On Dec 4, 12:40 am, Trevor Turk [EMAIL PROTECTED] wrote: On Dec 3, 11:39 am, Swap [EMAIL PROTECTED] wrote: There was a small change. They fixed a bug with since_id where it would set it as 0 if the status had been deleted (#77). It looks like they now require a count parameter as well. So what's a good workaround? Request the next page if you get 20 results? Too bad, but still doable :) - Trevor