#41

I know it’s somewhat arguable, but we won’t necessarily be requiring “user authentication” on v1.1 endpoints of the API.

#42

I’ve created a spreadsheet of all the resources that have been renamed or removed in v1.1. Perhaps this will be helpful to others: Modified resources in Twitter API v1.1 - Google Drive

Looking at this list, I can understand why certain resources have been removed (e.g. POST notification/follow and POST notification/leave were redundant with POST friendships/update). However, other resources have been removed with no replacement. I’m particularly disappointed to lose all the retweet resources. Will there be a way to get all the retweets by or to a particular user in Twitter API v1.1? Why was there no mention of this removal in the overview of changes?

#43

Hello!

We are analyst team, doing some researches on public internet activity and stuff. One of many things we are interested in, is analysing particular tweet or set of tweets audience. It was easily achievable using 1.0 API /statuses/:id/retweeted_by/ids.json and /followers/ids.json resources.

In API 1.1 nor those resources neither any replacement for them are presented. Can You please suggest any official way to know particular tweet audience? Is it reasonable to ask page parameter to /1.1/statuses/retweets/:id.json resource?

Since we do non online analysis, we can try to live with lower rate limits, i.e. longer time to collect data required, but we can’t live without data itself!

Thanks and regards,
Inbergo Team.

#44

Hey twitter folks, any updates on these questions?

#45

Most, if not all, of the retweet timelines were duplicative sources of data available in statuses/home_timeline, statuses/user_timeline, and statuses/retweets/id – you can extract that information from those methods instead. To get all recent retweets by a specific user, you can fetch their user timeline and extract the retweets from it.

#46

The limits in place are meant to serve the majority of user use cases. There are some outliers that will take longer to process within these limits. Cursoring is built in a way that will be resilient across longer periods of time.

#47

search_metadata->next_page response contains wrong parameters:

  • page (invalid)
  • rpp (replaced by count)

due to this possible issue I can’t understand how to loop through pages and previous tweets.
am I missing something or is it a real issue?

Thanks
Fede

#48

You can follow along with this bug here: [node:10734]. I’m working with the engineering team to resolve and the docs will be updated with the proper metadata response portion once this is resolved. You’ll need to use since_id and max_id to move between pseudo-“pages” of results. See [node:6213] for more info on best practices in navigating timelines.

#49

How would you get the equivalent of GET statuses/retweeted_to_user in v1.1?

#50

Understood! No more pagination!

Thanks!

#51

It would be helpful if there was an actual error returned in the body to clarify. For example this just returns an empty body:

curl -is https://api.twitter.com/1.1/statuses/mentions_timeline.json

#52

We ( http://tweettronics.com ) are built on 1.0, and on 1.0 assumptions since 2009. As it is we’re also grandfathered at higher limits for search which we need and want you to preserve.
1.) It sounds like you will not simply not support 1.0 but you are removing it from existence. Is that right? And if so, what are the cutoff dates and are the v1.1 endpoints fully operational now?
2.) Regarding search, i’m not clear on the limit of how many tweets we can obtain, paging or not. (We have never been a fan of the streaming API for a lot of reasons.)
Appreciate your answers. Thanks.

#53

You should be able to just redirect to the signed API requests from the JSON-P request to your own server.

That way the server only does the signing (shouldn’t take too much resources) and the web browser will issue the real API request to Twitter …

#54

Gravity is automatically fetching lists for each user you’re looking up, for example.

That makes lists a lot more interesting.

When you immediately see the lists that a user has created or is following, you get a better understanding of that user.

These kind of features won’t work with the new limits anymore, I think.

By the way, is the API 1.1 live already? Can you test it out right away?

#55

Hi there,

Currently the retweeted_by endpoint allows you to retrieve up to 800 retweeters of a tweet. It appears it didn’t make it to the list of endpoints in v1.1.

statuses/retweets/:id is in there. Is this limited to returning 100 retweeters total?

Is there still a way to retrieve up to 800 retweeters of a tweet via REST?

Thank you,
@Favstar

#56

In v1, it was possible to fetch up to 100 of my tweets that have been retweeted with a single request to GET statuses/retweets_of_me.

If I’m not mistaken, the only way to do the same thing in v1.1 is to call GET statuses/user_timeline. However, there is no guarantee that calling it once will return 100 retweeted statuses (since this resource returns all my tweets, not just the retweets ones). In the worst-case scenario, I’d have to call this API 16 times to retrieve 3,200 tweets before finding the first 100 retweets.

What could be achieved in a single request now could require as many as 16, which is more than is allowed in a single 15 minute window.

I’d strongly encourage you to rethink the rate limits on GET statuses/user_timeline, GET statuses/home_timeline, GET statuses/mentions_timeline, and GET statuses/retweets/:id, since these resources are being used to replace multiple resources that existed in v1 of the API.

Also, am I correct in stating that there’s no v1.1 API replacing GET statuses/retweeted_to_user? I’m surprised there was no mention of this in the announcement of v1.1. Removing existing functionality seems like worthy of inclusion in the overview of the changes.

#57

Yes I noticed that the retweet endpoints have gone, also that users/profile_image/ api has also gone, so the only way to get someone’s image is to call that user object instead

#58

Hello,

I was wondering whether applications that combine services will be at all effected given they follow the rules of the roads?

Our service combines Facebook and Twitter (and soon Instagram). The feeds, messages and notifications are merged into single feeds. This is not a traditional client and it doesn’t seem to go against any of the rules any more… but I just wanted to check to make sure?

Cheers!

#59

Have the daily (trends/daily.json) and weekly (trends/weekly) trends endpoints been removed?

#60

So if I understand you correctly, whitelisting will disappear in 1.1? If so, I would love to know how to get elevated access for certain API calls.

For my application (and I assume numerous others), whitelisting/elevated access rate is crucial, as the API endpoints and rate limits are tailored towards certain use cases like clients or Tweet analysis tools. And if a tool does something else (in my case network analysis/management), the API endpoints and rate limits simply do not fit.

For example, if a network analysis needs the following lists of all the people a user follows and you would like to generate an answer in the minute range, it would work

  • with whitelisting for all but the biggest accounts (up to 19,798 following)
  • with 1.0 limits only for quite small accounts (up to 345 following)
  • with 1.1 limits for almost no account (up to 14 following)

A couple of things that could help here:

  • The obvious one: Whitelisting as before.
  • Whitelisting the friends/ids and followers/ids calls only.
  • An endpoint allowing to batch retrieval of following/follower id lists (like users/lookup for users). It would be OK if this one would only work for cursor=-1.
  • Making the time window a lot bigger for friends/ids and followers/ids. For a network analysis, it is often fine to cache data for a week or so, as following lists do not change much over time. But to collect the data takes way too long with a 15 minute window. If an app could make a week’s worth of calls for a user in a minute, it could then cache it and do analysis based on that data for the next week.