Re: [twitter-dev] Annotations Hackfest Update - join in remotely!
Quoting Ryan Sarver rsar...@twitter.com: Hey all, Just wanted to update everyone and let you know that we are going to be extending the Annotations hackfest to anyone interested, regardless of whether or not you are able to make it to SF. We'll be providing a preview of Annotations to anyone interested with the caveat that it might get torn down again after the weekend is over if we feel like we need to make some changes based on the feedback from the weekend. Thank you!! It's going to be a fun weekend! ;-)
[twitter-dev] Re: New opt-in API features available today, May 26th: entities, retweets in timelines, custom oauth_callback schemes
Great work! Are there plans to include these features in streaming API? Thanks! On 26 maio, 19:22, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, We released some new features today that I'll summarize briefly here. *Entities* Raffi's already introduced the concept of entities to you in a previous post:http://bit.ly/boHXYv You can now retrieve entities for tweets by specifying a include_entities=true parameter to statuses/home_timeline, statuses/user_timeline, statuses/friends_timeline, and statuses/mentions API calls to receive additional per-tweet payloads dissecting parse-able elements from the tweet body like @mentions, links, and hashtags. It's really cool! Some examples of how entities are represented can be found here:http://dev.twitter.com/pages/tweet_entities *Retweets in Timelines* * *Many developers have asked for merged timelines including native retweets; for backwards-compatibility reasons this hasn't been possible in the past. Now you can include a include_rts=true parameter to statuses/user_timeline, statuses/friends_timeline, and statuses/mentions API calls to receive retweets inline in the payload. *OAuth callbacks with non-standard URI schemes* While you still can't set your default oauth_callback in your client application record to a URI schemes that aren't of the http or https variety, you can now dynamically set your oauth_callback on the request_token step of the OAuth dance to custom URI schemes. This is useful when your application is a web browser itself, or has the capability of registering custom URI schemes on the host operating system; a great, almost friction-free solution for those weary of the out-of-band OAuth flow. Since these features are new, we would appreciate any comments, suggestions, or notes on any bugs you discover while using them. Some relevant updated documentation:http://dev.twitter.com/doc/get/statuses/mentionshttp://dev.twitter.com/doc/get/statuses/friends_timelinehttp://dev.twitter.com/doc/get/statuses/home_timelinehttp://dev.twitter.com/doc/get/statuses/public_timeline Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod
[twitter-dev] OAuth home timeline
Hi, I start using OAuth for a desktop app, I have a very basic question, after my app successfully authenticated the user, how should my app call the OAuth home timeline api? how the URL should look like? I tried the following one, but it ends up using basic auth. http://twitter.com/statuses/friends_timeline.json?oauth_consumer_key=KEYoauth_nonce=NONCE8oauth_signature=Signatureoauth_signature_method=HMAC-SHA1oauth_timestamp=timeStamp Thank
Re: [twitter-dev] Re: New social events on User Streams
Cheers, thanks. *j* On Thu, May 27, 2010 at 12:55 AM, Mark McBride mmcbr...@twitter.com wrote: I'll be looking at the OAuth issue(s) this week ---Mark http://twitter.com/mccv On Wed, May 26, 2010 at 5:36 PM, Fabien Penso fabienpe...@gmail.com wrote: John, Any chance it moves so quickly than time is left to look at the issue I've posted? Subject was 'UserStream : bug with oauth connection' On Wed, May 26, 2010 at 11:08 AM, John Kalucki j...@twitter.com wrote: I had to remove unfollow messages until we can sort out a complicated issue. The block and unblock messages remain. Sorry for the regression -- we're trying to move quickly.
Re: [twitter-dev] Encrypted data over Twitter
On Wed, May 26, 2010 at 10:16:40AM -0700, John Adams wrote: I think you're referring to ITAR, most of which was repealed in 1997. Until 1996?1997, ITAR classified strong cryptography as arms and prohibited their export from the U.S. Times have changed quite a bit since then. Also, as I understood the matter at the time, ITAR only restricted international distribution of encryption technology (i.e., crypto algorithms and implementations of those algorithms) and didn't care at all about what might be done with the resulting ciphertext or where it might be sent. However... Amateur radio regulations in the US do include (or at least did include last I heard) an absolute ban on transmitting encrypted information. It used to be fairly common for ham radio operators to use packet radio technologies to transmit TCP/IP data over the amateur bands in order to get free roaming internet access; I expect this practice is less common today (thanks to widespread cellular data access), but not extinct. When using packet radio on amateur bands, ssh/ssl/etc. are not legal due to the crypto ban on those bands. I would expect encrypted tweets to be illgal under the same regulations, although that may be dependent on whether the receiver has the means to decrypt them. -- Dave Sherohman
[twitter-dev] Re: New opt-in API features available today, May 26th: entities, retweets in timelines, custom oauth_callback schemes
Thank you for fixing the issue of retweets not being included in timeline data! I reported the issue as soon as it arose, when the retweet feature was first introduced, and have been monitoring the situation ever since: http://code.google.com/p/twitter-api/issues/detail?id=1312
[twitter-dev] Re: New opt-in API features available today, May 26th: entities, retweets in timelines, custom oauth_callback schemes
+1 to the streaming request, as an option if possible. Thanks, Jebu On May 27, 6:03 am, Walter walte...@gmail.com wrote: Great work! Are there plans to include these features in streaming API? Thanks! On 26 maio, 19:22, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, We released some new features today that I'll summarize briefly here. *Entities* Raffi's already introduced the concept of entities to you in a previous post:http://bit.ly/boHXYv You can now retrieve entities for tweets by specifying a include_entities=true parameter to statuses/home_timeline, statuses/user_timeline, statuses/friends_timeline, and statuses/mentions API calls to receive additional per-tweet payloads dissecting parse-able elements from the tweet body like @mentions, links, and hashtags. It's really cool! Some examples of how entities are represented can be found here:http://dev.twitter.com/pages/tweet_entities *Retweets in Timelines* * *Many developers have asked for merged timelines including native retweets; for backwards-compatibility reasons this hasn't been possible in the past. Now you can include a include_rts=true parameter to statuses/user_timeline, statuses/friends_timeline, and statuses/mentions API calls to receive retweets inline in the payload. *OAuth callbacks with non-standard URI schemes* While you still can't set your default oauth_callback in your client application record to a URI schemes that aren't of the http or https variety, you can now dynamically set your oauth_callback on the request_token step of the OAuth dance to custom URI schemes. This is useful when your application is a web browser itself, or has the capability of registering custom URI schemes on the host operating system; a great, almost friction-free solution for those weary of the out-of-band OAuth flow. Since these features are new, we would appreciate any comments, suggestions, or notes on any bugs you discover while using them. Some relevant updated documentation:http://dev.twitter.com/doc/get/statuses/mentionshttp://dev.twitter.co... Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod
Re: [twitter-dev] Re: New opt-in API features available today, May 26th: entities, retweets in timelines, custom oauth_callback schemes
Thanks to Mark, #1 has been in the Streaming API for weeks now, but we have to coordinate a deploy before you can use it. The pacing is up to the annotations people. #2 and #3 don't apply to Streaming, it seems. On Thu, May 27, 2010 at 12:23 AM, Jebu Ittiachen jebu.ittiac...@gmail.comwrote: +1 to the streaming request, as an option if possible. Thanks, Jebu On May 27, 6:03 am, Walter walte...@gmail.com wrote: Great work! Are there plans to include these features in streaming API? Thanks! On 26 maio, 19:22, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, We released some new features today that I'll summarize briefly here. *Entities* Raffi's already introduced the concept of entities to you in a previous post:http://bit.ly/boHXYv You can now retrieve entities for tweets by specifying a include_entities=true parameter to statuses/home_timeline, statuses/user_timeline, statuses/friends_timeline, and statuses/mentions API calls to receive additional per-tweet payloads dissecting parse-able elements from the tweet body like @mentions, links, and hashtags. It's really cool! Some examples of how entities are represented can be found here:http://dev.twitter.com/pages/tweet_entities *Retweets in Timelines* * *Many developers have asked for merged timelines including native retweets; for backwards-compatibility reasons this hasn't been possible in the past. Now you can include a include_rts=true parameter to statuses/user_timeline, statuses/friends_timeline, and statuses/mentions API calls to receive retweets inline in the payload. *OAuth callbacks with non-standard URI schemes* While you still can't set your default oauth_callback in your client application record to a URI schemes that aren't of the http or https variety, you can now dynamically set your oauth_callback on the request_token step of the OAuth dance to custom URI schemes. This is useful when your application is a web browser itself, or has the capability of registering custom URI schemes on the host operating system; a great, almost friction-free solution for those weary of the out-of-band OAuth flow. Since these features are new, we would appreciate any comments, suggestions, or notes on any bugs you discover while using them. Some relevant updated documentation: http://dev.twitter.com/doc/get/statuses/mentionshttp://dev.twitter.co... Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod
Re: [twitter-dev] re: intermittent 401 and 502 during oauth process
Hi Taylor, Thanks for responding. I am using to get user public tweets using tweeter-APIs [Tweetr.getUserTimeLine() method]. Thanks regards, Bhushan On Wed, May 26, 2010 at 7:05 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: 400 errors usually mean the request was malformed in some way. Can you give some examples of the URLs you are trying to access and the method by which you're requesting? Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Tue, May 25, 2010 at 11:09 PM, Bhushan Garud garud.bhus...@gmail.com wrote: Hi All, I have got 400 error while accessing users public tweets. Can you please help me to resolve this error? Thanks regards, Bhushan On Wed, May 19, 2010 at 11:29 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Correct. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Wed, May 19, 2010 at 10:18 AM, Dossy Shiobara do...@panoptic.com wrote: Does this result in a response of Failed to validate oauth signature and token as well? On 5/19/10 11:26 AM, Taylor Singletary wrote: Hi James, Yes, right now we're throwing these kind of errors when our servers are stressed. We hope to have things more stable soon. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Wed, May 19, 2010 at 7:48 AM, wibblefish docherty.ja...@gmail.com mailto:docherty.ja...@gmail.com wrote: Hi All, I have just started to put together a small Twitter application but every so often I am seeing either a 401 Unauthorized or 502 Bad Gateway when acquiring a request token. Would it be normal to see this during twitter 'over capacity' periods? Cheers James -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
[twitter-dev] Unable to logout from twitter oauth api
HI Guys, My name is suresh working as php programmer .I integrated twitter oauth component.i integrated this component in my application for twitter signin.i am successfully login to the twitter using this component.after login i am succesfully redirecting back to my application.but when i am logout from my application i am again access twitter signin it is automatically login.in my logout i am completley destory the session.i know the twitter checking the cookies but i am unable to twitter cookies from my application.So scholars please help on this issue as early as possible. Thanks Suresh suresh.tum...@gmail.com
[twitter-dev] seems like something has changed - my application has stopped working
I am using the search api in a flash application, everything worked like clockwork until a few days ago. However, now it seems like the api has an issue with mi unit. Furthermore, if i have a search string with a space in it, it doesn't work i.e if i search for lady gaga i know this is not a good explanation, but i can't debug this at all - its like a ghost.
[twitter-dev] Re: New opt-in API features available today, May 26th: entities, retweets in timelines, custom oauth_callback schemes
On May 27, 12:22 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, We released some new features today that I'll summarize briefly here. *Entities* Raffi's already introduced the concept of entities to you in a previous post:http://bit.ly/boHXYv You can now retrieve entities for tweets by specifying a include_entities=true parameter to statuses/home_timeline, statuses/user_timeline, statuses/friends_timeline, and statuses/mentions API calls to receive additional per-tweet payloads dissecting parse-able elements from the tweet body like @mentions, links, and hashtags. It's really cool! Some examples of how entities are represented can be found here:http://dev.twitter.com/pages/tweet_entities Cool. There is just one issue in combination with the new include_rts flag; I've opened a ticket here: http://code.google.com/p/twitter-api/issues/detail?id=1652 *Retweets in Timelines* * *Many developers have asked for merged timelines including native retweets; for backwards-compatibility reasons this hasn't been possible in the past. Now you can include a include_rts=true parameter to statuses/user_timeline, statuses/friends_timeline, and statuses/mentions API calls to receive retweets inline in the payload. Sweet. Thanks for finally implementing this! - David
[twitter-dev] Do i need to create an app
Hi all really sorry about bothering you with this, i just have a quick question to ask. i currently have a CMS that i have coded from scratch within this i have included a twitter intergration so when one of our people using the CMS adds an article it will post it directly to our twitter profile, it currently doing this via a PHP class that i had found, using the username and password directly to post to twitter. the question is would i have to change this to OAuth, and would i need to create an application for it? as it isnt really an application as such is it? im kind of lost with this, should i create an app and then recode the way the CMS works to post to twitter using OAuth? im assuming i would need to create a callback page etc to get the authorization details that i would need is this correct? any help would be most appreciated thanks Dan
[twitter-dev] why am i not receiving the oauth_verifier in the callback parameters?
Hey all, I'm new to twitter development and am trying to get started. I'm currently using python and the oauth-python-twitter2 oauth client library and twitter api wrapper. My basic problem is when the user gets redirected back to my app after authorizing my app on twitter, I don't get back the oauth_verifier. I do see the oauth_token in my GET parameter, but nothing else. Am I missing something? If there was an error, where can I see that? thanks, ben
[twitter-dev] Twitter O Auth get friends statuses
Hi I have built an app where users login and send a tweet to their friends, I am retrieving a list of friends for them to choose from, but it is using up my rate limiter, is there any way to do this using the users rate limit?
[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING
Taylor, I'm glad Twitter thought to do this, but it still doesn't explain as clearly as Ryan's post here about what's acceptable and what's not. Not Acceptable: Paid Tweets injected into any timeline on a service that leverages the Twitter API (other than Promoted Tweets). This applies to any Twitter stream, whether user based, search based, or other. This makes it sound like Ryan was wrong, and actually confuses the issue again. From Ryan: This policy also *does not prohibit* services like Ad.ly that help facilitate those relationships or even help her post the ads to her timeline on her behalf. These sound like they are conflicting. Is Ryan correct, or not? What would also be helpful is a link to information on how the Promoted Tweets rev share works. On May 26, 9:20 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hello Everyone, We recently updated our Advertising FAQ to answer many of the questions that you may have.http://bit.ly/twitter-ad-faq Taylor On Wed, May 26, 2010 at 9:15 AM, Liz nwjersey...@gmail.com wrote: I hope some answers are forthcoming, James. Twitter doesn't seem very talkative.
[twitter-dev] Twitter Search request failed. error 420
Hello i was sending this request via php: status:http://search.twitter.com/ search.json?geocode=55.6762944,12.5681157,10mirpp=100 the reply i get is: 420 unused. failed to open stream: HTTP request failed! HTTP/1.1 Is this problem with my code or reliability of api?
Re: [twitter-dev] seems like something has changed - my application has stopped working
Can you share some of your example queries? Are you able to capture the response of your failed requests? We made some changes recently to the Search API on how it handles complex queries. Previously, there was a simple limit of 140 characters in the query string -- now we computationally calculate how complex a search query is and service it based off of that. The unfortunate side effect is that it's difficult to determine how complex a query is before trying it. Searches with many ORs and ANDs intermixed are obvious candidates, especially when they contain additional operators. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Thu, May 27, 2010 at 1:15 AM, yousef y.sekan...@googlemail.com wrote: I am using the search api in a flash application, everything worked like clockwork until a few days ago. However, now it seems like the api has an issue with mi unit. Furthermore, if i have a search string with a space in it, it doesn't work i.e if i search for lady gaga i know this is not a good explanation, but i can't debug this at all - its like a ghost.
[twitter-dev] Re: TwitterOAuth, two authentication calls, one works, one fails... why?
On 5/26/2010, Abraham Williams wrote: Are the scripts on the same server? Same version of PHP? Are they using the same accounts access tokens? Same consumer token? Yes, yes, yes, and yes. Since I posted, though, I figured out what the problem was. The second authentication _is_ working, but the verify credentials call that I made immediately afterward (to confirm that it's working) is not. I did the same after the first authentication call, and it worked there. This is equally baffling, but I can tweet, so it's not a show stopper. I'd still like to get my code working with the current version of your API code, and if you have any suggestions, I'd welcome then. (I posted about this several weeks ago but got no response. The problem is not the same; in that case the first authentication call's tweet doesn't work either.) But I'll have to defer that until I get my first implementation into production. -- Jonathan
[twitter-dev] Re: seems like something has changed - my application has stopped working
Hi Taylor, It were simple search queries, and I was unable to capture failed response. My application geocodes search results, when i changed distance units from miles to km it kinda worked but it was very glitchy. 2 hours ago when i checked everything worked fine, so I assume you guys must have changed something cause i haven't. On May 27, 2:36 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Can you share some of your example queries? Are you able to capture the response of your failed requests? We made some changes recently to the Search API on how it handles complex queries. Previously, there was a simple limit of 140 characters in the query string -- now we computationally calculate how complex a search query is and service it based off of that. The unfortunate side effect is that it's difficult to determine how complex a query is before trying it. Searches with many ORs and ANDs intermixed are obvious candidates, especially when they contain additional operators. Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod On Thu, May 27, 2010 at 1:15 AM, yousef y.sekan...@googlemail.com wrote: I am using the search api in a flash application, everything worked like clockwork until a few days ago. However, now it seems like the api has an issue with mi unit. Furthermore, if i have a search string with a space in it, it doesn't work i.e if i search for lady gaga i know this is not a good explanation, but i can't debug this at all - its like a ghost.
Re: [twitter-dev] Twitter Search request failed. error 420
420 is a rate limit. The actual error message in the response does state this. Requesting things more than every 20 seconds will not help your results be any fresher. Jonathan On Thu, May 27, 2010 at 6:29 AM, Karolis pkaro...@gmail.com wrote: Hello i was sending this request via php: status:http://search.twitter.com/ search.json?geocode=55.6762944,12.5681157,10mirpp=100http://search.twitter.com/%0Asearch.json?geocode=55.6762944,12.5681157,10mirpp=100 the reply i get is: 420 unused. failed to open stream: HTTP request failed! HTTP/1.1 Is this problem with my code or reliability of api?
[twitter-dev] OAuth UTF-8 issue
Hi,
I follow the example at http://dev.twitter.com/pages/auth in order to
authenticate and tweet and it works fine with their example: I tweet
successfully the sentence setting up my twitter 私のさえずりを設定する. But
then I try to tweet the just the sentence in plain English: setting
up my twitter and it fails, I get this message:
{request:/1/statuses/update.json,error:Incorrect signature}
I have tested and basically the idea is: if the sentence I want to
tweet has UTF-8 characters, it will work fine, posting everything; if
it doesn't have them, then I'll get the error message displayed.
Why can this happen? It seems an error with the URLEncode but, why
would it work in one string and not in a substring? Also, could anyone
tell me how accurate that error message is? Could it be something
different from the signature being incorrect?
Thanks
Re: [twitter-dev] OAuth UTF-8 issue
Can you share an example of what your signature base string looks like in
the case of you sending the plain English tweet?
There are some cases when we're under load where we're send a Cannot
authenticate you error, but it doesn't look like that's what is going on
here.
Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod
2010/5/27 Alvaro Montoro alvaromont...@gmail.com
Hi,
I follow the example at http://dev.twitter.com/pages/auth in order to
authenticate and tweet and it works fine with their example: I tweet
successfully the sentence setting up my twitter 私のさえずりを設定する. But
then I try to tweet the just the sentence in plain English: setting
up my twitter and it fails, I get this message:
{request:/1/statuses/update.json,error:Incorrect signature}
I have tested and basically the idea is: if the sentence I want to
tweet has UTF-8 characters, it will work fine, posting everything; if
it doesn't have them, then I'll get the error message displayed.
Why can this happen? It seems an error with the URLEncode but, why
would it work in one string and not in a substring? Also, could anyone
tell me how accurate that error message is? Could it be something
different from the signature being incorrect?
Thanks
[twitter-dev] Re: Annotations Hackfest
Hey Matt, Any chance there will be a video cast of the event. Would love to attend, but in St. Louis :) Thanks, Ryan Gremln.com On May 26, 2:36 pm, themattharris thematthar...@twitter.com wrote: Hey everyone, This week the Twitter Engineering team announced they are running an annotation Hackfest. The event will be this weekend (29-30 May) at Twitter HQ (795 Folsom St. San Francisco) and is free to attend. Places are limited so if you want to attend sign up today! If you are in the Bay Area this is a great opportunity to hack with Annotations and meet other Twitter developers. I'll be around for the event so if you want to share ideas and experiences with using the APIs, or just want to have a chat, come and say hi. More details and the signup form are on the Engineering team blog:http://engineering.twitter.com/2010/05/annotations-hackfest.html Best, Matt
[twitter-dev] Trends not currently supporting the callback parameter?
I have noticed a change with regards to the trends resource. for reference please check the following URLs 1) http://api.twitter.com/1/trends/current.json 2) http://api.twitter.com/1/trends/current.json?callback=foo 3) http://search.twitter.com/trends.json?callback=foo Currently, for me api.twitter.com trends/current.json is returning the same pure JSON payload regardless of the callback parameter. This is new behavior that has changed since I last used this resource. What I would expect, and is not the case, is that URL #2 with the callback parameter specified would return JSON wrapped in a function call, similar to how URL #3 behaves. Has anyone else noticed this? I have confirmed it myself with more than one location. Is this on purpose? Was a bug rolled out to production in a release? Am I missing the obvious. Please help. Thank you very much.
[twitter-dev] Re: Twitter Search request failed. error 420
We are seeing 420 errors on our account right now, today when we have not seeing them before...We have a pause in our search cycle with Twitter that has been sufficient to not cause us to exceed our whitelist allocation. Have you revised downward the whitelist limits? We have been using this api for more than 18months without much problem, but right now we are, and it's impactng our business. @JeffGreenberg jeffrey greenberg tweettronics.com On May 27, 7:18 am, Jonathan Reichhold jonathan.reichh...@gmail.com wrote: 420 is a rate limit. The actual error message in the response does state this. Requesting things more than every 20 seconds will not help your results be any fresher. Jonathan On Thu, May 27, 2010 at 6:29 AM, Karolis pkaro...@gmail.com wrote: Hello i was sending this request via php: status:http://search.twitter.com/ search.json?geocode=55.6762944,12.5681157,10mirpp=100http://search.twitter.com/%0Asearch.json?geocode=55.6762944,12.568115... the reply i get is: 420 unused. failed to open stream: HTTP request failed! HTTP/1.1 Is this problem with my code or reliability of api?
[twitter-dev] search.twitter.com 420 errors today when we did not get them before
We are seeing 420 errors on our account right now, today. We have not seen them hardly at all before... We have a pause in our search cycle with Twitter that has been sufficient to not cause us to exceed our whitelist allocation. Have you revised downward the whitelist limits in general or for us in particular? We have been using this api for more than 18months without much problem. Our production app is using basic auth: is that a factor? (We are going to switch to oauth later today). This change of behavior is impactng our business. @JeffGreenberg jeffrey greenberg tweettronics.com
[twitter-dev] Re: New opt-in API features available today, May 26th: entities, retweets in timelines, custom oauth_callback schemes
I've replied on the ticket but for the benefit of everyone here is the reply: Thanks. The entities in retweets will function for all retweets from now on. If you query a timeline which has retweets in it [1] you should find the entities are included and with the correct offsets. 1. twurl /1/statuses/user_timeline.xml? id=themattharriscount=5include_entities=trueinclude_rts=truetrim_user=true
[twitter-dev] Re: New opt-in API features available today, May 26th: entities, retweets in timelines, custom oauth_callback schemes
Will unicode urls be punycoded? Are there any plans to extend this to all returned tweets (search for example)? It seems its usefulness is suspect until it is available across the board due to the fact that a parser will have to exist client side until that happens.
[twitter-dev] Re: Status 401 on Streaming filter API with OAuth
Ah, This was know problem, wasn't this. Is there any place to check out know issues about APIs? -- Norio Suzuki
[twitter-dev] Widget Search problem
Hi, I have a problem with the Search widget. If i go on this page http://twitter.com/goodies/widget_search and type #habs OR attaquea5 on the search input, i got no result. If i take a look at the get parameter the q value is #habs+OR attaquea5. Look like something add the + sign. It always do that and its return no result.
[twitter-dev] Re: New opt-in API features available today, May 26th: entities, retweets in timelines, custom oauth_callback schemes
On May 27, 8:56 pm, themattharris thematthar...@twitter.com wrote: I've replied on the ticket but for the benefit of everyone here is the reply: Thanks. The entities in retweets will function for all retweets from now on. If you query a timeline which has retweets in it [1] you should find the entities are included and with the correct offsets. 1. twurl /1/statuses/user_timeline.xml? id=themattharriscount=5include_entities=trueinclude_rts=truetrim_user=t rue Doesn't work for JSON, only for XML. Have added a comment to the issue.
[twitter-dev] Social Graph Methods Page Size change?
I'm noticing now that page for friends and followers (for arbitrary user ids) are returning 100 users, not 5,000 as I'm seeing in the API docs. Is it my imagination that this has changed just in the last couple of days?
Re: [twitter-dev] Re: Status 401 on Streaming filter API with OAuth
Your report was definitely useful. I think it was reported here in two separate threads, but it's not like it was an issue that was known for days or weeks. In any case, this should be fixed on chirpstream now. We'll get the fix pushed out to stream.twitter.com soon. ---Mark http://twitter.com/mccv On Thu, May 27, 2010 at 12:40 PM, noki noris...@gmail.com wrote: Ah, This was know problem, wasn't this. Is there any place to check out know issues about APIs? -- Norio Suzuki
[twitter-dev] Search spam??
I just noticed this today - may have been going on for a while, though. I'm logged in on twitter.com. I have a few saved searches for some friends - about four of them with different groups of friends. What's in the search term is, for example, screen name 1 OR screen name 2. The screen names appear without @ signs. One of these searches is returning tweets that don't match either of the two screen names! They are returning tweets from the two screen names *plus* some tweets that appear to be from people trying to get me to click on links. These tweets do *not* have the characteristics of a Promoted Tweet. They aren't showing up at the top of the search - they're showing up in time sequence order. Has someone figured out how to game the search? Is Twitter testing something and not telling us? When I search for sn1 OR sn2 I do *not* want to receive tweets like this! http://twitter.com/rx8mall/status/14859299274
[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING
Mo, I think the word injected is causing the confusion. As I understand it it means: - I pull a list of tweets from the API into an array. - Before displaying the list to the user, I inject entries that look like tweets (but are actually entries I get paid to display) into that array. - Then I display the list to the user making it look as if everything in the list came from Twitter. As I said, that's how I understand it. But with that understanding, it does not make sense why Dick was going on about the infrastructure cost of Twitter, because this injection does not impact Twitter's infrastructure at all. It all happens exclusively on the application's server or the desktop or mobile device. Anyway, hopefully at some point in time there will be an authoritative and unambiguous explanation from Twitter. On May 27, 10:16 am, Mo maur...@moluv.com wrote: Taylor, I'm glad Twitter thought to do this, but it still doesn't explain as clearly as Ryan's post here about what's acceptable and what's not. Not Acceptable: Paid Tweets injected into any timeline on a service that leverages the Twitter API (other than Promoted Tweets). This applies to any Twitter stream, whether user based, search based, or other. This makes it sound like Ryan was wrong, and actually confuses the issue again. From Ryan: This policy also *does not prohibit* services like Ad.ly that help facilitate those relationships or even help her post the ads to her timeline on her behalf. These sound like they are conflicting. Is Ryan correct, or not? What would also be helpful is a link to information on how the Promoted Tweets rev share works. On May 26, 9:20 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hello Everyone, We recently updated our Advertising FAQ to answer many of the questions that you may have.http://bit.ly/twitter-ad-faq Taylor On Wed, May 26, 2010 at 9:15 AM, Liz nwjersey...@gmail.com wrote: I hope some answers are forthcoming, James. Twitter doesn't seem very talkative.
[twitter-dev] Important Notice on Incorrect API Endpoints for Search, REST, OAuth (+ some general tips!)
Hi Developers, A few quick points before I go into more detail: * For the Search API, you should *only* be using http://search.twitter.comto execute search requests. *Not* http://api.twitter.com/1/search or any other variation. * *Next week*, we plan to remove the erroneous, unsupported endpoint at http://api.twitter.com/1/search * All REST requests to the API should use the fully qualified hostname and API version in URLs: http://api.twitter.com/1/* -- no other version is valid at this time. * All OAuth negotiation steps should be over SSL and also at http://api.twitter.com -- but without a version. * Don't execute the same search query more often than every 20s and always use since_id on subsequent requests * Consider the streaming API if you're relying on search heavily to power your application *The Long-winded Approach* * * The only endpoint you should be using for search operations in the Twitter API today is http://search.twitter.com -- it doesn't require user authentication or OAuth -- simply identify yourself with a user-agent that is unique to your application. For those using http://twitter.com/search, http://api.twitter.com/search, or http://api.twitter.com/1/search -- you've been doing it wrong :) Though we should have rejected traffic to that end point long ago to avoid confusion, it was never intended as a valid resource for search queries. Next week, we'll be properly closing off this end point to avoid further confusion. If you have code today that uses the http://api.twitter.com or http:/twitter.com domains to execute search requests, be sure and update your code for the proper end point. You can find the Search API documentation at http://bit.ly/twitter-search-api Many users of the Search API are better served by using the Streaming API. If you use the search API to track the tweets of specific users, hashtags, or simple keyword queries, it is highly recommended that you use the Streaming API instead. You shouldn't issue the same request to the search API more frequently than once every 20 seconds -- if you issue the same query more frequently than that, you're in danger of getting blacklisted. In addition, if you find yourself repeating the same query frequently, be sure and make use of the since_id parameter on subsequent requests -- without it, you put undue stress on the search infrastructure and will also be in danger of blacklisting. While we're on the topic of using the proper endpoints, a general reminder about endpoints with the Twitter API: All REST resource requests, with the exception of Search, should be pointed at http://api.twitter.com/1/* -- always use the api subdomain and specify the version number (1). No other version number will be accepted for the API at this time and your requests will fail if you provide a different string or integer. All OAuth negotiation steps should be over SSL at https://api.twitter.com/oauth/* ( https://api.twitter.com/oauth/request_token;, https://api.twitter.com/oauth/authorize;, https://api.twitter.com/oauth/access_token;, https://api.twitter.com/oauth/authenticate;) Let us know if you have any concerns about the removal of the unofficial/unsupported search end point. We don't want to break people, but we also don't want you using unofficial API calls with substandard and unpredictable responses. Thanks! Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod
[twitter-dev] About OAuth of Twitter
We use OAuth login in our application for a long time, but the links are sth. like: http://twitter.com/oauth/request_token;, and we just found the new one should be sth. like http://api.twitter.com/oauth/request_token;. It seems what we have now is OAuth 1.0A as mentioned in documents. We are not sure what should we change to avoid broken after June 30th. Any suggestions? Thank you.
Re: [twitter-dev] About OAuth of Twitter
You're safe to continue using the non-api-subdomain version of OAuth for awhile longer (it won't disappear on June 30th), but we recommend switching to using the api subdomain (and SSL!) pro-actively in the event we decide to be stricter here in the future. But we have no immediate plans to invalidate such requests at this time. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Thu, May 27, 2010 at 3:17 PM, emagic emaginations...@gmail.com wrote: We use OAuth login in our application for a long time, but the links are sth. like: http://twitter.com/oauth/request_token;, and we just found the new one should be sth. like http://api.twitter.com/oauth/request_token;. It seems what we have now is OAuth 1.0A as mentioned in documents. We are not sure what should we change to avoid broken after June 30th. Any suggestions? Thank you.
[twitter-dev] Re: OAuth UTF-8 issue
Hi, thank you for the answer, this is an example of a sentence that
works and is tweeted correctly:
setting up my twitter 私のさえずりを設定する
and now an example of a sentence that is not tweeted because of
incorrect signature:
setting up my twitter
I find it interesting because it is a substring of the first sentence.
On May 27, 10:28 am, Taylor Singletary taylorsinglet...@twitter.com
wrote:
Can you share an example of what your signature base string looks like in
the case of you sending the plain English tweet?
There are some cases when we're under load where we're send a Cannot
authenticate you error, but it doesn't look like that's what is going on
here.
Taylor Singletary
Developer Advocate, Twitterhttp://twitter.com/episod
2010/5/27 Alvaro Montoro alvaromont...@gmail.com
Hi,
I follow the example athttp://dev.twitter.com/pages/authin order to
authenticate and tweet and it works fine with their example: I tweet
successfully the sentence setting up my twitter 私のさえずりを設定する. But
then I try to tweet the just the sentence in plain English: setting
up my twitter and it fails, I get this message:
{request:/1/statuses/update.json,error:Incorrect signature}
I have tested and basically the idea is: if the sentence I want to
tweet has UTF-8 characters, it will work fine, posting everything; if
it doesn't have them, then I'll get the error message displayed.
Why can this happen? It seems an error with the URLEncode but, why
would it work in one string and not in a substring? Also, could anyone
tell me how accurate that error message is? Could it be something
different from the signature being incorrect?
Thanks
[twitter-dev] Re: OAuth UTF-8 issue
Also, if I try to post something like: 私のさえずりを設定する, it works. In fact, if I try to post anything with a japanese character in it, the tweet will go through correctly.
[twitter-dev] Re: About OAuth of Twitter
Ok, I see. thank you for your reply. On May 27, 3:20 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: You're safe to continue using the non-api-subdomain version of OAuth for awhile longer (it won't disappear on June 30th), but we recommend switching to using the api subdomain (and SSL!) pro-actively in the event we decide to be stricter here in the future. But we have no immediate plans to invalidate such requests at this time. Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod On Thu, May 27, 2010 at 3:17 PM, emagic emaginations...@gmail.com wrote: We use OAuth login in our application for a long time, but the links are sth. like: http://twitter.com/oauth/request_token;, and we just found the new one should be sth. like http://api.twitter.com/oauth/request_token;. It seems what we have now is OAuth 1.0A as mentioned in documents. We are not sure what should we change to avoid broken after June 30th. Any suggestions? Thank you.
[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING
Dewald, Thanks for the clarification. What you're saying makes sense and is in line with what Ryan was saying. I hope you're right. On May 27, 2:35 pm, Dewald Pretorius dpr...@gmail.com wrote: Mo, I think the word injected is causing the confusion. As I understand it it means: - I pull a list of tweets from the API into an array. - Before displaying the list to the user, I inject entries that look like tweets (but are actually entries I get paid to display) into that array. - Then I display the list to the user making it look as if everything in the list came from Twitter. As I said, that's how I understand it. But with that understanding, it does not make sense why Dick was going on about the infrastructure cost of Twitter, because this injection does not impact Twitter's infrastructure at all. It all happens exclusively on the application's server or the desktop or mobile device. Anyway, hopefully at some point in time there will be an authoritative and unambiguous explanation from Twitter. On May 27, 10:16 am, Mo maur...@moluv.com wrote: Taylor, I'm glad Twitter thought to do this, but it still doesn't explain as clearly as Ryan's post here about what's acceptable and what's not. Not Acceptable: Paid Tweets injected into any timeline on a service that leverages the Twitter API (other than Promoted Tweets). This applies to any Twitter stream, whether user based, search based, or other. This makes it sound like Ryan was wrong, and actually confuses the issue again. From Ryan: This policy also *does not prohibit* services like Ad.ly that help facilitate those relationships or even help her post the ads to her timeline on her behalf. These sound like they are conflicting. Is Ryan correct, or not? What would also be helpful is a link to information on how the Promoted Tweets rev share works. On May 26, 9:20 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hello Everyone, We recently updated our Advertising FAQ to answer many of the questions that you may have.http://bit.ly/twitter-ad-faq Taylor On Wed, May 26, 2010 at 9:15 AM, Liz nwjersey...@gmail.com wrote: I hope some answers are forthcoming, James. Twitter doesn't seem very talkative.
[twitter-dev] OAuth questions (GET, Access Tokens)
I am writing a desktop application to easily allow a user to manage multiple Twitter accounts (Such as for promotional purposes) and easily switch between them without having to manually log out, then log back in again. There are a lot of things not explained well with OAuth. 1. Can an application have multiple access tokens open at the same time, for different accounts? Or is the previous access token invalidated as soon as a new user is authorized? 2. If it can have multiple access tokens, are the Token and Token Secret the only information needed to authorize a request for a certain user? 3. When using the authorization headers and generating the base signature, are all of the authorization parameters (excluding oauth_signature) merged with the request parameters?
Re: [twitter-dev] OAuth questions (GET, Access Tokens)
Hi, We're always working on making the documentation better and I can see how some of these aspects of OAuth would be difficult to grok when you're used to other means. One way I like to think about this is: Think of your HTTP request as an envelope. The URL is the address. Your consumer key and access token is the sender's address. Your POST body is inside the envelope. And the postage, ink, bar codes and such are your HTTP headers, including your OAuth Authorization to send this letter to the recipient. Specific Answers below: 1. Can an application have multiple access tokens open at the same time, for different accounts? Or is the previous access token invalidated as soon as a new user is authorized? Absolutely. Your application is its own entity. You could have 1 user. You could have 5 users. You could have millions. Each of those users in your system would have an access token associated with them (which is actually two fields you would store, an oauth_token and oauth_token_secret). The only time access tokens expire in our OAuth implementation is when the user manually severs the connection in their settings page, or if you re-prompt them for access by invoking the OAuth flow again, which gives them the opportunity to deny the request. The user is always in control of whether your application can act on their behalf. 2. If it can have multiple access tokens, are the Token and Token Secret the only information needed to authorize a request for a certain user? They're all you need to identify the user, yes. But you still must sign the request using your consumer secret (API secret) as per the OAuth specification. 3. When using the authorization headers and generating the base signature, are all of the authorization parameters (excluding oauth_signature) merged with the request parameters? If you use authorization headers, you don't include any OAuth-related query parameters on the query string. I recommend using headers exclusively, as query-string based OAuth is more difficult to debug and it's better to separate concerns: you're requesting a resource, and the OAuth parameters don't have anything to do with the resource identified in the URL. The authorization HTTP header is more appropriate. While you don't include OAuth parameters on the query string, you DO need to still include any query parameters that are particular to the resource you are requesting (like page, count, etc.) in addition to putting them into the signature base string construction algorithm. If you have POST parameters, they still need to be sent in the POST body. Nothing really changes here in the way you use the API as far as the basics of using REST go. Taylor
[twitter-dev] Twitter Error codes/statements?
So i am writing my catch expressions for twitter when parsing the response from twitter is there any error codes or definite strings for certain reasons. example not following user, or other errors? Thank you!
[twitter-dev] Entities not working?
For most of the day I was getting the new entities just fine, but for the last hour or two my home_timeline XML request is met with the Something is technically wrong. page as the response. I am using PHP EpiTwitter. This works fine: $twitterInfo = $twitterObj-get_statusesHome_timeline(array(count = $numTweets)); This was working for most of the day, but not recently: $twitterInfo = $twitterObj-get_statusesHome_timeline(array(count = $numTweets , include_entities = true));
[twitter-dev] Re: OAuth questions (GET, Access Tokens)
That answers all of my questions. Thank you very much! On May 27, 4:41 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi, We're always working on making the documentation better and I can see how some of these aspects of OAuth would be difficult to grok when you're used to other means. One way I like to think about this is: Think of your HTTP request as an envelope. The URL is the address. Your consumer key and access token is the sender's address. Your POST body is inside the envelope. And the postage, ink, bar codes and such are your HTTP headers, including your OAuth Authorization to send this letter to the recipient. Specific Answers below: 1. Can an application have multiple access tokens open at the same time, for different accounts? Or is the previous access token invalidated as soon as a new user is authorized? Absolutely. Your application is its own entity. You could have 1 user. You could have 5 users. You could have millions. Each of those users in your system would have an access token associated with them (which is actually two fields you would store, an oauth_token and oauth_token_secret). The only time access tokens expire in our OAuth implementation is when the user manually severs the connection in their settings page, or if you re-prompt them for access by invoking the OAuth flow again, which gives them the opportunity to deny the request. The user is always in control of whether your application can act on their behalf. 2. If it can have multiple access tokens, are the Token and Token Secret the only information needed to authorize a request for a certain user? They're all you need to identify the user, yes. But you still must sign the request using your consumer secret (API secret) as per the OAuth specification. 3. When using the authorization headers and generating the base signature, are all of the authorization parameters (excluding oauth_signature) merged with the request parameters? If you use authorization headers, you don't include any OAuth-related query parameters on the query string. I recommend using headers exclusively, as query-string based OAuth is more difficult to debug and it's better to separate concerns: you're requesting a resource, and the OAuth parameters don't have anything to do with the resource identified in the URL. The authorization HTTP header is more appropriate. While you don't include OAuth parameters on the query string, you DO need to still include any query parameters that are particular to the resource you are requesting (like page, count, etc.) in addition to putting them into the signature base string construction algorithm. If you have POST parameters, they still need to be sent in the POST body. Nothing really changes here in the way you use the API as far as the basics of using REST go. Taylor
[twitter-dev] Re: Important Notice on Incorrect API Endpoints for Search, REST, OAuth (+ some general tips!)
Are you all aware of this bug? http://code.google.com/p/twitter-api/issues/detail?id=1154 We can't reliably use since_id for searches until this is fixed. On May 27, 6:12 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, A few quick points before I go into more detail: * For the Search API, you should *only* be usinghttp://search.twitter.comtoexecute search requests. *Not*http://api.twitter.com/1/searchor any other variation. * *Next week*, we plan to remove the erroneous, unsupported endpoint athttp://api.twitter.com/1/search * All REST requests to the API should use the fully qualified hostname and API version in URLs:http://api.twitter.com/1/*-- no other version is valid at this time. * All OAuth negotiation steps should be over SSL and also athttp://api.twitter.com-- but without a version. * Don't execute the same search query more often than every 20s and always use since_id on subsequent requests * Consider the streaming API if you're relying on search heavily to power your application *The Long-winded Approach* * * The only endpoint you should be using for search operations in the Twitter API today ishttp://search.twitter.com-- it doesn't require user authentication or OAuth -- simply identify yourself with a user-agent that is unique to your application. For those usinghttp://twitter.com/search,http://api.twitter.com/search, orhttp://api.twitter.com/1/search-- you've been doing it wrong :) Though we should have rejected traffic to that end point long ago to avoid confusion, it was never intended as a valid resource for search queries. Next week, we'll be properly closing off this end point to avoid further confusion. If you have code today that uses thehttp://api.twitter.comor http:/twitter.com domains to execute search requests, be sure and update your code for the proper end point. You can find the Search API documentation athttp://bit.ly/twitter-search-api Many users of the Search API are better served by using the Streaming API. If you use the search API to track the tweets of specific users, hashtags, or simple keyword queries, it is highly recommended that you use the Streaming API instead. You shouldn't issue the same request to the search API more frequently than once every 20 seconds -- if you issue the same query more frequently than that, you're in danger of getting blacklisted. In addition, if you find yourself repeating the same query frequently, be sure and make use of the since_id parameter on subsequent requests -- without it, you put undue stress on the search infrastructure and will also be in danger of blacklisting. While we're on the topic of using the proper endpoints, a general reminder about endpoints with the Twitter API: All REST resource requests, with the exception of Search, should be pointed athttp://api.twitter.com/1/*-- always use the api subdomain and specify the version number (1). No other version number will be accepted for the API at this time and your requests will fail if you provide a different string or integer. All OAuth negotiation steps should be over SSL athttps://api.twitter.com/oauth/*(https://api.twitter.com/oauth/request_token;, https://api.twitter.com/oauth/authorize;, https://api.twitter.com/oauth/access_token;, https://api.twitter.com/oauth/authenticate;) Let us know if you have any concerns about the removal of the unofficial/unsupported search end point. We don't want to break people, but we also don't want you using unofficial API calls with substandard and unpredictable responses. Thanks! Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod
[twitter-dev] Re: users.lookup() pulls by friendship date
So it's the same one that I was talking about. They haven't specified any sorting rules in the doc, are you sure about it? Before all that, I hope you know that the lookup API can be used to retrieve info about ANY twitter user. So it does not matter if that user is your friend. How will the sorting be applied then? -Nischal On May 27, 5:18 am, cballou ball...@gmail.com wrote: The link is: http://dev.twitter.com/doc/get/users/lookup It actually returns the full dataset for up to 100 users. The returned data is sorted by your newest friendship in descending order. This functionality is quite minimal and could definitely be expanded upon like I suggested above. I was just wondering if there were any possibly hidden parameters I could pass in to change the count, cursor position, etc. On May 26, 1:22 am, nischalshetty nischalshett...@gmail.com wrote: Are you talking about this -http://api.twitter.com/version/users/lookup.format The above API returns whatever ids you have passed. Am I missing something? -Nischal On May 26, 4:38 am, cballou ball...@gmail.com wrote: Nobody? On May 25, 12:14 pm, cballou ball...@gmail.com wrote: I really don't like the fact that calling users.lookup() returns the last 100 users I have friended. Is there a way to retrieve users in a more random fashion or with some kind of ordering (ascending/descending)? I'm looking for more optional parameters. Suppose, for instance, that I have 500 friends. I would not want to pull my last 100 friends when making this API call. I might want to, however, pull a random sampling of 100 of those friends. I may also want to pull a particular number of friends (i.e. imposing a limit on the request). I would propose that there be additional filtering parameters for this request: sort: asc/desc/random (default desc) limit: 1-100 (default 100) Can anybody clarify and expand upon this for me?
[twitter-dev] Re: Important Notice on Incorrect API Endpoints for Search, REST, OAuth (+ some general tips!)
Hi Taylor, I've filed a bug report about using since_id with search 6 months ago after my client users complained about empty / no search results: http://bit.ly/since_id Is this bug fixed already? If not, how can we use since_id with the Search API so that it is giving us some results and not just an empty set? Also, I'm using a proxy for my users from China and have therefore used the user auth'ed version of the Search api (http:// api.twitter.com/1/search...) If I'm switching to search.twitter.com, will I run into API limits for my proxy then? Thanks for any help Ole @ mobileways.de / #Gravity Twitter Client for S60 Symbian -- http://twitter.com/janole On 28 Mai, 00:12, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, A few quick points before I go into more detail: * For the Search API, you should *only* be usinghttp://search.twitter.comtoexecute search requests. *Not*http://api.twitter.com/1/searchor any other variation. * *Next week*, we plan to remove the erroneous, unsupported endpoint athttp://api.twitter.com/1/search * All REST requests to the API should use the fully qualified hostname and API version in URLs:http://api.twitter.com/1/*-- no other version is valid at this time. * All OAuth negotiation steps should be over SSL and also athttp://api.twitter.com-- but without a version. * Don't execute the same search query more often than every 20s and always use since_id on subsequent requests * Consider the streaming API if you're relying on search heavily to power your application *The Long-winded Approach* * * The only endpoint you should be using for search operations in the Twitter API today ishttp://search.twitter.com-- it doesn't require user authentication or OAuth -- simply identify yourself with a user-agent that is unique to your application. For those usinghttp://twitter.com/search,http://api.twitter.com/search, orhttp://api.twitter.com/1/search-- you've been doing it wrong :) Though we should have rejected traffic to that end point long ago to avoid confusion, it was never intended as a valid resource for search queries. Next week, we'll be properly closing off this end point to avoid further confusion. If you have code today that uses thehttp://api.twitter.comor http:/twitter.com domains to execute search requests, be sure and update your code for the proper end point. You can find the Search API documentation athttp://bit.ly/twitter-search-api Many users of the Search API are better served by using the Streaming API. If you use the search API to track the tweets of specific users, hashtags, or simple keyword queries, it is highly recommended that you use the Streaming API instead. You shouldn't issue the same request to the search API more frequently than once every 20 seconds -- if you issue the same query more frequently than that, you're in danger of getting blacklisted. In addition, if you find yourself repeating the same query frequently, be sure and make use of the since_id parameter on subsequent requests -- without it, you put undue stress on the search infrastructure and will also be in danger of blacklisting. While we're on the topic of using the proper endpoints, a general reminder about endpoints with the Twitter API: All REST resource requests, with the exception of Search, should be pointed athttp://api.twitter.com/1/*-- always use the api subdomain and specify the version number (1). No other version number will be accepted for the API at this time and your requests will fail if you provide a different string or integer. All OAuth negotiation steps should be over SSL athttps://api.twitter.com/oauth/*(https://api.twitter.com/oauth/request_token;, https://api.twitter.com/oauth/authorize;, https://api.twitter.com/oauth/access_token;, https://api.twitter.com/oauth/authenticate;) Let us know if you have any concerns about the removal of the unofficial/unsupported search end point. We don't want to break people, but we also don't want you using unofficial API calls with substandard and unpredictable responses. Thanks! Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod
