Following up on API housekeeping

kurrik
@kurrik Arne Roomann-Kurrik

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.

1 year 32 weeks ago

Replies

manton
@manton Manton Reece

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?

1 year 32 weeks ago
kurrik
@kurrik Arne Roomann-Kurrik

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!

1 year 32 weeks ago
mnbvcxzl3
@mnbvcxzl3 mnbvcxzl3

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.

1 year 32 weeks ago
kurrik
@kurrik Arne Roomann-Kurrik

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.

1 year 31 weeks ago
monsieurjplus
@monsieurjplus Monsieurjplus

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.

1 year 32 weeks ago
episod
@episod Taylor Singletary

No, search.twitter.com/search.json is not involved in this particular series of deprecations.

1 year 31 weeks ago
monsieurjplus
@monsieurjplus Monsieurjplus

Thank you for the quick reply :-)

1 year 31 weeks ago
sferik
@sferik Erik Michaels-Ober

Have these changes gone into effect? I expected to see an announcement shortly after you flipped the switch on these endpoints.

1 year 29 weeks ago
episod
@episod Taylor Singletary

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.

1 year 29 weeks ago
jasoncosta
@jasoncosta Jason Costa

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!

1 year 28 weeks ago
znmeb
@znmeb ᙇᓐ M. Edward Borasky

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/.

1 year 28 weeks ago
episod
@episod Taylor Singletary

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?

1 year 28 weeks ago
davidzupec
@davidzupec David Zupec

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 : )

1 year 27 weeks ago
davidzupec
@davidzupec David Zupec

Thanks for all your help guys, I figured it out : )

1 year 27 weeks ago
pkprose
@pkprose Patrick Kenney

David I'm in the same boat using a json callback. Care to share what you figured out?

1 year 27 weeks ago
mediagrunt
@mediagrunt mediagrunt

ditto

1 year 27 weeks ago
davidzupec
@davidzupec David Zupec

Hello, see what @mr_pchlee has below. That worked for me : )

1 year 27 weeks ago
olliecorn
@olliecorn oliver

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:

  1. <script type="text/javascript" src="https://api.twitter.com/1/javascripts/blogger.js"></script>
  2.  
  3. <script type="text/javascript" src="https://api.twitter.com/1/account/myclient.json?callback=twitterCallback2&count=1">
  4. </script>
1 year 27 weeks ago
mr_pchlee
@mr_pchlee Phil Lee

Using the following made it work again for me :D

  1. <script type="text/javascript" src="http://twitter.com/javascripts/blogger.js"></script>
  2.  
  3. <script type="text/javascript" src="https://api.twitter.com/1/statuses/user_timeline.json?screen_name=mr_pchlee&callback=twitterCallback2&count=4"></script>

Hope this helps ;)

1 year 27 weeks ago
meduza25
@meduza25 meduza

Thanks, this helped me!

1 year 27 weeks ago
TheNumber27
@TheNumber27 Matt Hills

Thanks very much - exactly what I was after to fix it! :)

1 year 27 weeks ago
PrttyShnySprkly
@PrttyShnySprkly Pretty Shiny Sparkly

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

1 year 27 weeks ago
mr_pchlee
@mr_pchlee Phil Lee
  1. https://api.twitter.com/1/statuses/user_timeline.json?screen_name=PrttyShnySprkly&callback=twitterCallback2&count=1

Should hopefully work for you :)

1 year 27 weeks ago
Agbelayi
@Agbelayi Isaac Toluwa

I am exicted with the new development. I pray it will serve better & fulfill it purpose.
Kudo to twetter

1 year 28 weeks ago
sircmpwn
@sircmpwn Drew DeVault

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.

1 year 27 weeks ago
episod
@episod Taylor Singletary

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.

1 year 27 weeks ago
sircmpwn
@sircmpwn Drew DeVault

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?

1 year 27 weeks ago
episod
@episod Taylor Singletary

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.

1 year 27 weeks ago
sircmpwn
@sircmpwn Drew DeVault

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.

1 year 27 weeks ago
sferik
@sferik Erik Michaels-Ober

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.

1 year 27 weeks ago
sircmpwn
@sircmpwn Drew DeVault

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.

1 year 27 weeks ago
lrauf
@lrauf Laurent Raufaste

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 ;)

1 year 27 weeks ago
MokumsKid
@MokumsKid Lorenzo

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}]}

1 year 27 weeks ago
episod
@episod Taylor Singletary

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

  1. $code = $tmhOAuth->request('POST', $tmhOAuth->url('1.1/statuses/update'), array(
  2.   'status' => 'My Twitter Message'
  3. ));

Instead of:

  1. $code = $tmhOAuth->request('POST', $tmhOAuth->url('statuses/update'), array(
  2.   'status' => 'My Twitter Message'
  3. ));
1 year 27 weeks ago
MokumsKid
@MokumsKid Lorenzo

Ah, could not retrieve from the mainpost that the URL needed to be changed at 1.1. Thanks, it's working again!

  • Lorenzo
1 year 27 weeks ago
RetweetRank
@RetweetRank Retweet Rank

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.

1 year 27 weeks ago
episod
@episod Taylor Singletary

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.

1 year 27 weeks ago
RetweetRank
@RetweetRank Retweet Rank

Got it. Somehow the previous token/secret expired on changing app access level.

1 year 27 weeks ago
episod
@episod Taylor Singletary

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.

1 year 27 weeks ago
nivs
@nivs Niv Singer

Will whitelist rate limits apply to version 1.1 endpoints?

1 year 24 weeks ago
episod
@episod Taylor Singletary

No, account and IP address whitelisting have no bearing on API v1.1.

1 year 24 weeks ago
pupeluve_4u
@pupeluve_4u lampai gathong

why? still expired on canging?

1 year 27 weeks ago
ravimathur15
@ravimathur15 Ravi Mathur

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 :(

1 year 27 weeks ago
KeshavKalra1
@KeshavKalra1 Keshav Kalra

i just hate this thing

1 year 27 weeks ago
WeitingWeng
@WeitingWeng Tim Weng

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.

1 year 27 weeks ago
episod
@episod Taylor Singletary

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.

1 year 27 weeks ago
aliceffekt
@aliceffekt Devine Lu Linvega

I'm using twitter-async and what do I need to change to make it work with this new version ?

1 year 27 weeks ago
episod
@episod Taylor Singletary

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

1 year 27 weeks ago
ChynthiaFang
@ChynthiaFang Chynthia

why i can't receive any mentions from my friends although they already tweeted it?

1 year 27 weeks ago
WORLDbytes
@WORLDbytes WORLDbytes

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&amp;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

1 year 27 weeks ago