Discussing API v1.1

episod · 2012-10-17T14:48:11.000Z

Make sure you’re using versioning in your URLs – it’s /1.1/statuses/update.json or /1/statuses/update.json you want to use when accessing resource URLs. Be explicit in your code.

codedeluxe · 2012-10-18T08:08:24.000Z

“You have exceeded the maximum number of widgets”

Really? Only a few dozen widgets and no ability to dynamically populate a search widget?

Has Twitter decided to destroy itself? Useless

TheUberGuy · 2012-10-18T18:50:10.000Z

Hi Taylor,
I’m seeing the rate limit for the home timeline, mentions, and DMs combined into a single rate of 15 calls per hour across all three, this doesn’t seem correct based on the 1.1 docs. For example, my first call to the home timeline resource returns and says I have 14 calls left. The next call I make is to the mentions timeline, this returns and says I have 13 calls left. The next one I make is to DMs, and when it returns it says I have 12 calls left. Shouldn’t each of these be independent of the others? They all say they will reset at the exact same date/time. Am I reading the docs wrong or am I seeing a bug?

episod · 2012-10-18T19:05:01.000Z

This is a bug we’re working to resolve currently. Will have an
official public ticket for it soon. Thanks!

TheUberGuy · 2012-10-18T19:16:29.000Z

Thanks so much for the speedy reply.

episod · 2012-10-18T21:54:11.000Z

For the most part, you should see this resolved now. Doing a bit more review on a couple edge cases that may still exist, but this aspect should be resolved.

aki · 2012-10-19T02:58:27.000Z

I find the rate limiting of lists/statuses to be too low, or not designed right. Each list acts like a single timeline, and each one of them should receive 15 calls / window. I can see how this would be very hard to implement, but it would really help a lot of people.

For example, performing social analysis to obtain someone’s interests by looking at each list would be extremely difficult to perform with this 15 calls / window limitation. For example, if we were to fetch latest 800 tweets for each list, it would cost 4 API calls per list. If a user have or subscribed to more than 3 lists (which is very common for lists users), we will have to delay the process of analysis before getting back to the user with a result, which severely degrades the user experience. Sure, we can fetch all members (lists/members rate limit is too low by the way. lists/memberIds would help a lot.) and simulate the result of the call by using various other APIs, but I thought the lists APIs were implemented to ease the pain of developers implementing lists-like features manually, and to endorse the server side maintenance of alternate timelines.

I can see how this could affect scalability severely, but I really think it is important to re-think this part of the rate limit design.

Thank you,

episod · 2012-10-19T03:13:04.000Z

Hi @aki,

I definitely recognize the value in raising the limits for lists/statuses and hope to have good things to announce about its rate limit in 1.1 soon.

aki · 2012-10-19T03:24:22.000Z

Thanks a lot for the quick response! I’m glad to know that you guys are aware of the issue

VideoBoothSW · 2012-10-20T10:07:02.000Z

Currently we have a application for posting tweets to user’s accounts with text and URLS, this has all been working fine untill this update using the new 1.1 url. It seems that if one number gets into the URL we are posting it bring back a ‘401 Unauthorized’ error.

So we have tried using as a test : http://www.a-b_c.com/ - this works but if using http://www.123.com/ it brings back that 401 error.

I’m completely stumped to why this isn’t working now on any of the twitter api domains? We tried switching back to the old url but still no joy. So if any number gets into the url, it doesn’t post. please help

Thank you

episod · 2012-10-22T14:57:37.000Z

This is unusual. I would very very closely identify how you’re encoding URLs in this field when setting the status. Make sure that you’re following the HTTP spec exactly and that your library or framework isn’t trying to be extra helpful, or at least be fully aware of any extra helpful things it is trying to do for you.

episod · 2012-10-30T21:00:45.000Z

I’m happy to announce that API v1.1 now supports the [node:12187] timeline, a simple way to access the most recently retweeted tweets authored by the authenticating user.

Though you may find it still supports v1’s page parameter, like all of API v1.1’s timeline methods, see [node:6213] for instructions on the proper usage of since_id, max_id, and count. The page parameter support will simply be removed in the coming days.

sferik · 2012-10-30T23:02:41.000Z

This is great! Thank you so much.

Any chance of bringing back GET statuses/retweeted_to_user?

Hidimba1 · 2012-10-31T01:16:34.000Z

Twitter API 1.1 is designed carefully by communists who live in pit the of hell.

To_aru_User · 2012-10-31T01:37:35.000Z

Why on earth have the ‘source’ of API v1.1 updates changed into ‘API’ at all?

FlockOfBirds · 2012-10-31T10:23:33.000Z

Hi @episod, any news on the formal avenues to request elevated access? The new limits will basically make network analysis so slow that most users won’t accept it, and that makes us quite nervous.

episod · 2012-10-31T22:01:40.000Z

While we haven’t formalized this yet, you can fill out https://support.twitter.com/forms/platform and request elevated limits in the meantime. Be sure and give some reasonable projetions on the specific methods you plan to use and how many requests you think a user would reasonably perform per 15 minute window on those methods.

episod · 2012-10-31T22:07:42.000Z

This method will not be making a comeback in API v1.1 – the timeline from which these retweets are taken, statuses/home_timeline, is very volatile and preparing the seldom used statuses/retweeted_to_user view of that timeline can be particularly taxing – especially in relation to its use in API v1.

I’m of course interested in hearing about any particularly worthwhile use cases with this method that aren’t served by self-filtering the home timeline or a user stream though.

FlockOfBirds · 2012-11-01T14:38:25.000Z

Thanks @episod!
There is no option to request elevated access to the REST API on that page, should I use “I need elevated access to the streaming API”?

episod · 2012-11-01T14:59:47.000Z

Either that or the “I have an API policy question not covered by these points”