Hi,
As you may recall from @episod's API Housekeeping blogpost in March, we noted that it was time to clean up a number of legacy remnants that caused developer confusion and operational inefficiencies. We're moving forward on that now and will be making the following changes on 9/25:
- All non-versioned API endpoints will go away. Though you may occasionally find these endpoints responding as we ramp down, expect them to be gone in two weeks. This list includes:
- All API endpoints on www.twitter.com and twitter.com.
- Endpoints on api.twitter.com without /1, /1.1 or /oauth in the fully qualified URL.
- We'll be removing support for the public timeline: api.twitter.com/1/statuses/public_timeline.
Lastly, we will not default "include_*" parameters to on as initially announced, since this behavior has been implemented in API v1.1.
Please ensure that you've removed any deprecated functionality by 9/25 in order to for your application to continue working smoothly. If you have any questions or concerns, please post them here.
Replies
Thanks for the update. There's one change mentioned in the original "housekeeping" blog post that I don't see here: removing the page parameter. Is pagination being turned off on 9/25 or will it also wait until API v1.1?
To be clear, we're still planning on removing the page parameter, ATOM support, and the deprecated methods from 1.0. The only real difference is that the include_* defaults will not be changed.
Sorry for not being clearer in the original post!
Since we are all going to move on to 1.1 in March, why not keep everything as is for now?
Now we have to test this soon-to-be-obsolete 1.0 system to work by 9/25, then redesign the whole thing and test it again by March next year. That's too much disruption on developers.
I agree that it's painful to have to juggle both sets of changes at once. However, this announcement was made in March. There's been a lot of time to update and test code to make sure you weren't hitting deprecated endpoints.
Of course we're here to help if you run into any issues migrating. Please let us know.
Hello @kurrik.
Thanks for the update.
Does that mean queries like http://search.twitter.com/search.json will be obsolete on 9/25? (and we will have to query with https://api.twitter.com/1.1/search/)
Thanks in advance.
No, search.twitter.com/search.json is not involved in this particular series of deprecations.
Thank you for the quick reply :-)
Have these changes gone into effect? I expected to see an announcement shortly after you flipped the switch on these endpoints.
We should have updated via @twitterapi, but there's another slight delay in flipping the switch. We're now looking at Thursday at the earliest; we'll send an update from @twitterapi when we have a more solid date/time.
Hi everyone - just a quick update that these changes are going to start taking place today and will continue in a staggered fashion over the coming days. In particular, it's worth noting that the public timeline (api.twitter.com/1/statuses/public_timeline) will be going away later today. Thanks!
Are trends/daily and trends/weekly going to get ported over to 1.1? Those are the only 1.0 endpoints I use that don't seem to be in 1.1/.
There are no plans to port those methods to 1.1 at this time -- the (stale) data available in those methods is available through GET trends/place. By monitoring that endpoint instead, you can build your own equivalent of trends/daily or trends/weekly for your studies.
What kind of specific use cases do you have with the daily and weekly methods that aren't served by the available trends methods?
Hello, I'm a bit of a beginner when it comes to the api but since the public_timeline is gone I'm not familiar with what to replace this with below? twitter.com/statuses/user_timeline/davidzupec.json?callback=twitterCallback2&count=1
Thanks for your help : )
Thanks for all your help guys, I figured it out : )
David I'm in the same boat using a json callback. Care to share what you figured out?
ditto
Hello, see what @mr_pchlee has below. That worked for me : )
I have a client with a wp site, pulling in his latest tweet using the following js, sounds like I may need to request access to his twitter account to authenticate something, as well as swap out/modify this code? can someone walk me through the specific steps, I feel close but still lost. BIG THANKS in advance:
<script type="text/javascript" src="https://api.twitter.com/1/javascripts/blogger.js"></script><script type="text/javascript" src="https://api.twitter.com/1/account/myclient.json?callback=twitterCallback2&count=1"></script>Using the following made it work again for me :D
Hope this helps ;)
Thanks, this helped me!
Thanks very much - exactly what I was after to fix it! :)
I'm using this same method and it disappeared two days ago. Can somebody help me with what I should change it to?
Currently I am using: https://twitter.com/statuses/user_timeline/PrttyShnySprkly.json?callback=twitterCallback2&count=1
Should hopefully work for you :)
I am exicted with the new development. I pray it will serve better & fulfill it purpose.
Kudo to twetter
Hundreds of IRC bots that push tweets to channels, as well as hundreds of applications elsewhere are now dead. Please, bring back some means of pulling tweets without authentication - bots can't really do OAuth.
If you're using any kind of "unversioned" endpoint, you'll need to move to a versioned one. Version 1 of the API is still active until March 2013. It's "version zero" of the API that is finally being removed now.
Good: https://api.twitter.com/1/statuses/user_timeline.json?screen_name=episod
Bad: https://twitter.com/statuses/user_timeline/episod.json
Bad: https://api.twitter.com/statuses/user_timeline/episod.json
Bad: https://twitter.com/1/statuses/user_timeline/episod.json
Bots are perfectly capable of performing OAuth. A consumer key, secret, access token, and access token secret and a compatible library are all that's necessary.
Not everyone has access to a nice OAuth library, but that's beside the point. What's so bad about the old URL that it has to be turned off? Hundreds of existing services are now broken until who knows when, why is that necessary?
We've been announcing that these unversioned endpoints were deprecated for multiple years now. There's been more than enough time to revise software to leveraging version 1 of the API -- without requiring anyone to leverage OAuth.
Now we're multiple years after the announcement of version 1 of the API and we're moving to version 1.1. While version 1 strongly encouraged the use of OAuth, it is now required in 1.1. Applications must identify themselves to request data from Twitter from now on and OAuth is the mechanism we've chosen to represent that identity.
The fact that it's been announced for a while doesn't make it any less impactful. People don't update, because requiring authentication for things your average web user doesn't require authentication for is ridiculous.
You don't actually need an OAuth library to write a bot. Just register an app at https://dev.twitter.com/apps and you'll automatically be granted an OAuth access token/secret pair (in addition to a consumer key/secret pair). You can combine those with one of a variety of 3rd-party libraries for talking to the Twitter API. Allow me to recommend this Ruby gem, which has already been fully updated to support Twitter API v1.1: https://github.com/sferik/twitter
Taylor has repeatedly dodged the question "Why is this necessary?" so I'll offer my personal view: Twitter is a business. It has over a thousand employees, thousands of servers, and swanky multi-level office in the high-rent district of San Francisco (rimshot). These things cost money, on the order of hundreds of millions of dollars per year. Every time you make an API request, it costs Twitter a little bit of money. You pay nothing. Twitter can't keep paying for these things forever without introducing a significant stream of revenue, on the order of hundreds of millions of dollars per year.
It has become increasingly clear over the past two years that Twitter's first major revenue stream will come from selling advertising. For advertising to be effective (i.e. for advertisers to actually pay for it), Twitter needs to control the experience. Specifically, Twitter needs to control how ads are displayed and that they are displayed. Even more specifically, this means they need to wield the ability to ban clients who don't obey the "Developer Rules of the Road" or "Display Requirements". This is why client authentication is necessary. If Twitter can't ban bad actors, someone could create a clone Twitter client that blocks all the ads. If enough people use that client, Twitter would not be able to sustain itself as a business. OAuth is necessary so that Twitter can continue to exist. It can't run on venture capital forever.
Through this lens, I think API v1.1 makes a lot of sense and actually seems pretty reasonable. If you don't like it, you don't have to use Twitter, a valuable service that you've never been asked to pay a penny for, as a developer or as a user.
I understand the need to produce revenue, but I don't see how this helps. API users don't see an ad either way. The only advertising benefit I can see is that they have to view a few pages on Twitter.com while setting up an account, and the tech savvy people involved probably have adblock. In fact, it theoretically costs more to require authentication, because each request requires https, which is a tick on the cost of a certificate from a trusted authority. All I see this change doing is encouraging people to crawl HTML as a pseudo-API, which I'm sure you wouldn't like. A good rule of thumb is that you should require API-level authentication for things that a web-level user has to be authenticated for. Otherwise, you annoy developers and encourage workarounds.
You are so right
Twitter is successful because the data was simply available.
We'll see in 10 years if it's always the case ;)
I'm using the TmhOAuth-PHP-library, with methods still like these: "statuses/update", but i'm also offline..
{"errors":[{"message":"Sorry, that page does not exist","code":34}]}
Can you share an example of the code you use to execute statuses/update? tmhOAuth doesn't assume an API version, you must include it within the resource URL fragments you point it at.
You want code that looks like
Instead of:
Ah, could not retrieve from the mainpost that the URL needed to be changed at 1.1. Thanks, it's working again!
Are 1.0 rate limit whitelists gone today? We had 20,000 queries/hour whitelist for @RetweetRank. The rate limit seems to be just hat seems to be no longer there from today? I was assuming it will continue till March '13.
Whitelisted accounts and IP addresses should continue having their whitelisting active on version 1 endpoints. Verify that the URLs you're using are correct and contain the api subdomain and /1/ preceding all other resource path elements.
Got it. Somehow the previous token/secret expired on changing app access level.
Yeah, the strings that represent an access token change when permissions transit between levels (such as RO to RW or RW to RW+DM) as well as if the permission is revoked and then renegotiated again.
Will whitelist rate limits apply to version 1.1 endpoints?
No, account and IP address whitelisting have no bearing on API v1.1.
why? still expired on canging?
This is ridiculous all my apps stopped working without any notice It should have been made public with a lot more noise so that everyone gets it like public timeline of facebook.
Moreover i dont find any reason to change to the new urls it was working like a dream for me and the next moment it's gone :(
i just hate this thing
Dear, Mr. Singletary
Could your team re-open those "OLD" URLs for several week, We are using those URLs on our iOS app, and the iOS apps can't change the code immediately, we have to get reviewed by apple, and it takes more than 1 week. Could you give us more time? we are very appreciated for your help.
We've had these URLs announced as deprecated for a few years now and began more loudly notifying people to migrate back in March 2012. We've kept the endpoints functioning well past their expiration date. I know it's an inconvenience, but you'll just need to make do with the reality that the endpoints are now finally retired.
I'm using twitter-async and what do I need to change to make it work with this new version ?
It looks like that latest version of the library leverages the correct 1.0 endpoints: https://github.com/jmathai/twitter-async/blob/master/EpiTwitter.php
But the library has not yet been updated to work with version 1.1
why i can't receive any mentions from my friends although they already tweeted it?
Hi,
We are trying to get our latest tweets showing on the website again. We've created an Application, and have the correct URL syntax in place on our site:
<script type="text/javascript" src="https://api.twitter.com/1.1/statuses/user_timeline.json?screen_name=worldbytes&count=20"></script>What we are stuck on is how to authenticate. I've read through your oAuth docs but can't find examples - I'm a front-end developer so much of it is beyond me. Is it even possible to get tweets using JavaScript in this way any more?
Cheers