Problems pdating thousands of apps to v1.1


#1

Hi, I have tried posting here a couple times, and tried the support ticket system but still have no response in months. It’s down to the last month and I need to know a solution now or discontinue twitter support and recommend all our customers to switch to other platforms.

We have 25,000 mobile apps built by our customers through a simple drag & drop UI that only ever creates public twitter timelines inside the mobile app. We use the v1 API and it has worked great so far. The idea of the apps is to get our customers’ end-users/visitors (these are mostly small business info apps) to get the info they need as quickly as possible, then get them out. No, we don’t want to ask users to log in just to see public data, we don’t want or need that level of responsibility for just serving public data.

We could try having a single user token for all our apps but it would expire frequently I imagine. Or try a user-less token but they’re still not available yet, and apparently won’t have much higher of a limit anyways. We tried to use the embedded timelines then discovered it has to be done on twitter.com and forces the user to leave our builder UI and spend a couple minutes on something that only took a second before. I’ve seen mentions months ago that you were working on having an API or some way to automate the creation of embedded timelines, but this hasn’t arrive yet either.

Why are you sunsetting an API that doesn’t have equivalent functions in the new API? Why haven’t you responded to any of my posts or support tickets? If there was some kind of cost/payment you required for greater access we’d be willing to entertain the idea, but I don’t even see that anywhere.

I need a response ASAP.


#2

Not every application that was built on APi v1 has an easy upgrade path to API v1.1. The requirement of authentication is a big hurdle for a few classes of applications.

Additionally, just because the data is “public” doesn’t mean an application shouldn’t need to identify itself from the other millions of applications making requests to the API. It’s really no less public, but I don’t think you came here to argue the relative publicness of data.

It sounds like each of these 25,000 mobile apps are individual applications, and each should have their own API key. That was the intended model in API v1, and it’s still the model in API v1.1. It was just easy for you to choose a more frictionless model with unauthenticated API requests being available.

It’s understandable that end-users of these applications shouldn’t necessarily need to authenticate with a Twitter account, and app-only auth might be the right solution on a per-app basis for these. Though Tweets are much less potent when they are not actionable, and the best way to make them actionable in an application is by leveraging user-based auth (or perhaps web intents).

Ideally your framework provides the ability for the developer of these applications to provide their own API keys. Once application-only auth is released, you would likely leverage that on a per-app basis. Otherwise, you can go ahead and implement with full user-based OAuth 1.0a today.


#3

Hi, thanks for the reply.

The problem with the API key approach is our “developers” are mostly just average people building an app with a drag & drop UI, not programmers. The pitch is that they build a mobile webapp in a few minutes, and its deployed right away (app store/native is an option, but few take that option). We’re a lot like a cloud CMS, except for touch-based mobile apps.

For actionability, most of the tweets that are in the apps are stuff like “10% off hair care products today”, stuff that’s relevant to the end user to know, and putting that behind a login barrier hurts the business trying to get that message out. We used web intents in v1 to do retweet, etc before.

I recognize we’re probably going to be forced to spent a lot of development time coming up with a solution we don’t like, but is there any chance you can let us know if the “automated embedded timelines” (IE, we use a code to create a widget, or a widget API of some sort) is still a planned feature, and if there’s an estimated timeline (even if vague). It’d be nice to know that at least there might be something more elegant again in the future.

Thank you