Premium search for tweets from: protected account


#1

Hello,

I have a long-established app associated with Twitter handle N (as I’ll call it) that searches for tweets from another account that contain a video. When I use the standard API, that app is able to find tweets even if the target account T is protected, as long as N follows T. The endpoint I am using there is https://api.twitter.com/1.1/statuses/user_timeline.json.

Since I created that app, I found that the Standard API no longer reliably returns all the relevant tweets (roughly, since the Premium API was introduced :)). So I am trying out the Premium API, using the endpoint https://api.twitter.com/1.1/tweets/search/…, still in association with N.

However, I have found that using that API with the ‘from:T has:video’ operators no longer returns tweets while T is protected. If I temporarily unprotect T and make a new post, it works i.e. I retrieve the new post.

Is this the expected behaviour? Is there a workaround? It’s essential for my application that my particular app can run through tweets in a protected account this way. Obviously, the circumstances are that the target account T has allowed N to follow it, in order to get through the protection.

Many thanks


#2

Protected accounts have never been available via the search APIs


#3

I’ve done it routinely for several years via the endpoint I specified. Obviously, only with the proviso that the account being searched has accepted the app’s account as a follower (as I said in my message). Why shouldn’t this be possible? If I used Twitter on the web or in the app while logged into the follower account I’d be able to see all those tweets.


#4

Hi Tim,
Unlike the regular search endpoint, the premium endpoint doesn’t use the authenticated user token, it uses an app level bearer token, so the endpoint has no idea which user is doing the search, hence it can’t return protected tweets.


#5

My misunderstanding/misreading on the endpoint piece, as I saw the Premium category, but didn’t check that you were comparing standard and premium. It does indeed make a difference since you’re more commonly using a bearer token without the user context on premium. Apologies if I misspoke in my previous comment.


#6

Thanks for your reply. Just to be clear, are you saying that it is the expected behavour under the premium API for protected tweets not to be returned in a search query, even under the circumstances I have described? I guess I don’t see the logic, given that the Twitter account associated with my app (i.e. the security principal behind the bearer token) can see those tweets via the web or the Twitter app. (Not to mention that at least some of the protected tweets are returned under the standard API with identical credentials.)


#7

As far as i know, this is expected behaviour. Any kind of search on twitter is built using public tweets only. The only way to get protected account tweets is using the standard api, like you were using at the start - with: 1.1/statuses/user_timeline.json provided that the user token used is from an account that is allowed to follow the protected user. Streaming protected accounts also doesn’t work (last time i checked).

I do remember a long time ago, protected accounts did appear in web search - but this didn’t last, also that could have been due to the protected account not being protected for a while and having their tweets still in the index.


#8

Understand, but this is the app context, not the user context. Your app could be used by many users, it just happens to be run by you under a bearer token, which carries no specific credential for any user, yours or any other.

Totally get that this may seem confusing.

Also, please be aware that the standard search API is completely different to premium and enterprise. Standard search is an ~11 year old API acquired by Twitter back then with very limited updates since. Premium and enterprise are entirely new, actively developed, but built with a different intent and auth model. Yes, you will see different results from a signed-in search on the app or website than you may from a bearer token for an API app on a premium search; this is by design.


#9

Thanks. I hadn’t realised the auth model had changed in the move to the premium API.

Are there plans (& a timeline) for removing the standard API?


#10

There’s a roadmap item for improved search but no current timeline we can for when this may switch over - plans are somewhat in flux as API 1.1 ages and as we think deeply about the external API surface. When there is concrete information to share, I hope to be one of your key contacts. For the foreseeable future the best bets are: standard API search (user Auth but limited index); premium full archive and 30-day options (rolling monthly billing); or enterprise annual subscriptions.