I am fairly new to this. I have to make sure that some twitter code written over god knows how long ago with this company I have only been with a year and a half will work with API version 1.1 (some of it 3rd party, made by Abraham Williams, http://abrah.am)

I am really not getting clear answers ANYWHERE.

First, twitter indicates that as long as you have OAuth, everything should be cool. That is, if you also fix the “endpoints”. I guess these are various access URLs. I am curious as to why twitter does not tell us exactly what those endpoints are for API 1.1. There is no room for speculation with computer programming. You either get the URL/string/code/password/function name right or you don’t. In some cases, if you do not have each and every line of code perfect, the entire application blows up.

If I ran a multimillion dollar company that untold numbers of businesses and individuals tightly integrated their applications with and I was going to make a major change that demanded that everyone updates or else their apps no longer work, I would tell everyone exactly, precisely what lines of code need to change to avoid these potentially embarrassing and destructive hassles.

I would make a line item sheet of what needs to be changed to what. For example, in the library of code I have to deal with, I see “https://api.twitter.com/1/

I get the impression that this should be changed, but to what? In the code I have to work with I changed it to both “https://api.twitter.com/1_1/” and also “https://api.twitter.com/1.1/”. But, neither of these urls work, whereas “https://api.twitter.com/1/” does work.

(was working with the php TwitterOAuth class by Abraham Williams)

What is odd that twitter seems to indicate on various pages that it should be “https://api.twitter.com/1.1/” with various GET examples here:

https://dev.twitter.com/docs/api/1.1

May I suggest whoever does the technical writing for twitter please take a look at this book?

Do you know if access to http://urls.api.twitter.com/ will be shutdown when the 1.1 API goes in to effect on 3/5? We currently query this to get the Tweet count of articles. For example:

http://urls.api.twitter.com/1/urls/count.json?url=http://nba.si.com/2013/02/26/kobe-bryant-los-angeles-lakers-playoffs-guarantee/&callback=jQuery152028114859224297106_1361926882592&_=1361926883356

Would love to know if we’re going to have to rewrite this or if our current method of getting this count will continue to work post 1.1.

urls.api.twitter.com is not a valid API endpoint – it’s an underlying detail of our Tweet Button architecture. You would be wise to not use or rely on it regardless of its relation to the API retirement process.

Taylor, we have an application that analyzes a collection of tweets to select a small subset from it based on certain algorithms. The application pulls data from the search api, and works in a ‘userless’ mode, where the users do not need to log-in or authenticate to view the results.

For such apps, what is the recommended way of authentication till an application-only context authentication becomes available? Can we use a certain pre-set number of user-contexts to continue fetching the data or is there a better method available.

Hi, thanks for having these threads. It helps a lot!

I just need a confirmation about the profile_pictures
At the moment I use
https://api.twitter.com/1/users/profile_image/#{username} to access the profile picture of a user.
But with v 1.1 I have to go through OAuth and get the pic from the profile_image_url field in the GET users/show, right? Thanks!

Yes, that is correct.

You can always use a dedicated access token in the meantime while you’re waiting for app-only auth. The rate limits afforded to the app-only context won’t be much different than the already existent per-user rate limits.

I’ve been using this URL to get profile images for quite sometime now -
https://api.twitter.com/1/users/profile_image/#{username}

So for example my profile image can be found here -
https://api.twitter.com/1/users/profile_image/_rishabhp

If i read it correct, the API retires or stops working on 5th march for unauthenticated calls (I guess the aformentioned process is considered as unauthenticated calls too). So, will this approach of fetching profile images stop working? If yes, then what’s the easiest and best alternative ?

I was looking through this - https://dev.twitter.com/docs/api/1.1/get/users/show - and I tried the example request shown there through the browser itself - https://api.twitter.com/1.1/users/show.json?screen_name=rsarver - unfortunately it gives me “{“errors”:[{“message”:“Bad Authentication data”,“code”:215}]}”.

But still, the issue is, it’ll return JSON, which means I’ll have to do some server fetching and parsing on my own server and then store images in my database or something similar (hope you get the idea). I would actually like to know a way in v1.1 where I can use direct URLs to profile images.

Looking forward to your response!

There is no direct way to use API v1.1 for just profile images – API v1’s feature that provided this was often used in unintended ways counter to the documentation, as the SRC attribute in IMG tags. You’ll need to make authenticated requests to canonical sources of user information (users/show or users/lookup) to retrieve the most recent profile image URL, then use the instructions in [node:10796] to derive the version you’re looking for.

I view tweets via an RSS reader using the following code:

https://api.twitter.com/1/statuses/user_timeline.rss?screen_name=example1

As of March 5th, what code should I use instead to accomplish exactly the same thing?

It’s no longer possible to accomplish exactly the same thing. RSS feeds are effectively discontinued.

What’s the best way we can test from our browser if we’re seeing the blackout?

To answer my own question, I’m now seeing 410 responses for urls like https://api.twitter.com/1/statuses/user_timeline.json?include_entities=true&include_rts=true&screen_name=twitter&count=2

Is it possible to have some hint about why there are many missing tweets in search widgets and how they are selected?
http://digitalia.fm/live-test

The moment we’ve been waiting for is here. The API version 1.0 is officially blacked out right now. My old widget code (left in a test page only for the purpose of testing this event) is showing an empty timeline as expected. :slight_smile:

Hi There! During the blackout we were returned with a 200 error. Any thoughts on what this can mean? All of our calls are through the API with OAuth for signing in to our App and to post a Tweet via our App. Thank you for any guidance! Joe/ShoutOmatic

Uhh… so, instead of simply pulling a public link with curl to do the simple task of displaying a timeline, now you have to jump through some hoops to obtain special access keys, then use a third party library to generate single-use tokens to access public data?

I’m perfectly capable of doing this, but a lot of people won’t be, so you will be seeing a lot of broken Twitter feeds for the foreseeable future. What exactly is the rationale for requiring this complexity for data you might as well scrape from the Twitter page itself? Seriously, how could anyone think that this was a good idea?

Is the only way to tell if you’re using REST API v1 by checking during the blackout times and see if the applications recieve error 410 Reponses? I’m jumping in the middle of my team’s development, and not sure to know what differences to look out for into v1.1. Thanks.

You should look into the API methods you’re explicitly calling via whatever libraries you’re using. API v1 paths can be identified by matching the following patterns:

If the API call isn’t going to https://api.twitter.com/1.1/*, then it’s probably a API v1-era call.

We’re noticing that the search widgets are displaying, but the list widgets stopped displaying. They were working one day, now only giving the “Tweets from @theopenmat/acc-wrestling” message. Defeats the purpose of an embed if it’s only linking to a twitter page anyway.

Search widget works, list widget does not.

Example: http://awn.theopenmat.com/2013/03/twitter-updates-acc-championships/