Discussion around Planning API v1's Retirement

episod · 2013-02-05T23:23:15.000Z

Hi developers,

This thread is for discussing the recent [node:14708, title=“Planning for API v1’s Retirement”] blog post. Please address any questions or concerns you have about the API v1 retirement plan here.

Thanks,
@episod

DustyReagan · 2013-02-05T23:43:25.000Z

These blackout tests will be super helpful in the transition. Thanks for setting those up!

ApplePedlar · 2013-02-06T05:44:38.000Z

When is a blackout test for authenticated requests?

jnoleau · 2013-02-06T09:04:09.000Z

/1/help/test.json will stay ? there is no equivalent in 1.1 to send a unauthenticated “HEAD” request in order to sync local clock with twitter’s server clock.

episod · 2013-02-06T15:59:12.000Z

We’ll announce those dates in the near future.

sperte · 2013-02-06T19:30:05.000Z

Will search/tweets still require user context, or will an app be able to use client authentication?

episod · 2013-02-06T19:49:58.000Z

/search/tweets is a method that will support application-only authentication once it is released. The rate limits will be somewhat conservative, so if you’re fronting search for more than a few end-users, you’ll likely still want to go the access token route.

adamwride · 2013-02-06T22:12:02.000Z

In the post you say “The @Anywhere framework will be permanently retired on March 5th, as planned.”

Right now we need to enter each of our domains so that Twitter OAuth will work on that domain.

Is this going away? Are we doing something wrong?

episod · 2013-02-06T22:20:24.000Z

The domains feature associated with @Anywhere only applied to usage of @Anywhere. Any domains you’ve defined with your application in that “domains” tab will be considered moot and eventually wiped away.

Our OAuth 1.0A implementation does not look to this list of domains.

mvn_raja · 2013-02-07T13:12:58.000Z

In the recent announcement, you mentioned that the API v1.0 will not be shutting off on 05-Mar.
Till what date are the v1.0 APIs supported?

episod · 2013-02-07T15:11:00.000Z

We’ll give more details on that soon. Consider that the March 5 date was already a deadline, and to strive to be ready by it. You won’t have much longer after that date.

adamwride · 2013-02-07T18:40:32.000Z

Thanks Taylor. We took a second look and indeed we were using the wrong API version for user info extraction.

johnbillion · 2013-02-08T16:24:00.000Z

I’d like to ask about the status of embedded Tweets. The API docs for embedding Tweets (https://dev.twitter.com/docs/embedded-tweets) states the following:

“Some content management systems like WordPress have created an optimized workflow for embedding Tweets. In WordPress you can simply copy the URL for a Tweet and paste it on a single line in your post. WordPress will do the rest of the work to insert the proper embed code and make the Tweet appear in your content.”

Members of the WordPress development team have expressed concern that embedded Tweets will cease working in WordPress, which uses v1 of the API.

Requiring OAuth authentication for an OEmbed is completely ridiculous. What are the plans for embedded Tweets in v1.1 of the API? Are there any plans for continuing support for embedded Tweets using v1 of the API?

Many thanks.

episod · 2013-02-08T16:50:58.000Z

We’re working out a solution for oEmbed and will let everyone know what that is in this thread. Stay tuned.

jnoleau · 2013-02-08T17:57:54.000Z

I don’t know if you see my question but what is the good way to sync clock with Twitter server clock without “/1/help/test.json” (no equivalent in 1.1). “This method is great for sending a HEAD request to determine our servers current time.”

Thanks a lot.

episod · 2013-02-08T18:12:31.000Z

I don’t have a good answer for you on this yet. You can still send a HEAD request to nearly any Twitter endpoint. Or make a call without authentication to any endpoint and get a response with a Date header in it. There are a few ways to accomplish this goal aside from a HEAD request to help/test.json.

cryptographite · 2013-02-08T23:07:00.000Z

When will Application Tokens be made available and usable for API calls? It has been stated repeatedly that these would be implemented “before the March 5th cutoff,” but I have yet to see any movement on this front.

For instance, it is incredibly useful for us to be able to call users/show in a user-less context.

Edit: This is where you stated it previously: https://dev.twitter.com/comment/reply/10644/29372

episod · 2013-02-11T14:47:55.000Z

We’ll release app-only auth when it’s ready. March 5th is the beginning of the end but not the end itself.

randallb · 2013-02-12T00:53:33.000Z

Is there a timetable for releasing this info?

EDIT: Just saw below. I’ll patiently wait, getting our user auth flow ready in the meantime.

Background: Our app, a way for TV stations to take tweets and put them on-air, currently uses the unauthenticated search platform. With 1.1, we’re going to likely have to get users to auth each individual user, which is a ux nightmare but understandable from your side. Ideally, we’d like to be able to provide fallback access using app tokens, to bridge the gap between authenticated and unauth’d.

tushar7saxena · 2013-02-13T11:15:30.000Z

I am currently in the process of developing an app for a major Marathon event for iPhone. The app has a twitter sheet which currently displays the tweets that are present on the timeline of the said event. Currently we are using v1.0 Twitter API. After the black out test on March 5th, is there a chance of Twitter reverting back to v1.0 if any problem arises or are they going to stick with v1.1 in any case. Please revert back asap as we are currently nearing completion of development and on the verge of launching the app on the app store.