The user ids in the search system are different for historical reasons. The plan is to merge the formats and 
provide the same user information as a timeline in the next major version of the API. That will correct this issue.

Any news on this ? Because it really 'blows' ...

This is set to be fixed in the next version of the API. Hopefully that will be directly after OAuth.

Also:
 - A single twitter user can have several search api user id
 - A single search api user id can in fact point to several twitter accounts

Basically it's just a mapping between a screen_name and an integer ... So if a user
changes screen name and someone else takes his old screen name, the latter will also
get his search id and the former will have a new search_id ...

So if you want to _really_ know who posted a message I think the only way to get the
real tweet thru the api (the tweet_id is correct) ...

PS: I'm posting this here purely for information to people using the search API.

Consider this another request to merge these two fields. It's really confusing to get
a user_id back from the Twitter Search API only to discover that it's practically
useless.

I was building an app that used a combination of the Twitter Search API and the new
Social Graph methods but because of this mismatch I think I'll have to shelve the
project until this gets sorted out. Shame.

Couldn't agree more with the comments above, just spent an hour troubleshooting an
issue to realise the search API from_user_id does not match a actual twitter user's API.

You should probably make this a bit clearer in your doco.

Using the suggestion of looking up the persons username is not good because a user
can change their username.

The only way, is make ANOTHER lookup of the twitter tweet ID and then do another
lookup of the users profile based on the twitter user ID returned from that.

Would be nice to get this fixed. 

Another vote for getting this fixed.

Thanks.

Nice, also I filled up a DB wit 4000 Users with wrong not matching IDs. Please warn about that or better fix it. 
Why not give uique IDs. And if a user changes the name, we have the ID to identify.

Yes, this is really annoying please fix!

The "fix" is the next API. In the mean time I'm going to remove the elements to
prevent confusion. 

Huh ... what ???

I maintain a huge search_id <-> user_id mapping table internally, if you remove the user_id simply, that's 
obviously gonna break my parsing code. When do you plan on doing this ?

I would have planned on doing it soon (this week) since I assumed nobody was using it
and everybody is complaining about it. I guess I'll leave it for the time being and
the fix will have to be the next version of the API.

Well, it is confusing, that's true, but I think that just making it clear in the doc here : http://apiwiki.twitter.com/Search+API+Documentation

Just something that would state that the user_id is not the same as for the rest of the api and can't be used for 
cross reference, pointing to this issue for detail would be a big help to avoid new user confusion.

 Issue 414  has been merged into this issue.

Another vote for getting this fixed.

This issue has been recoreded in the future roadmap:
http://apiwiki.twitter.com/V2-Roadmap

Marking "Invalid" so these issues don't clutter the main view of issues. All are tracked on http://apiwiki.twitter.com/V2-Roadmap

Hi. will this issue be fixed or this remains unfixed? How much it will take to fix it?

V2, my friend, V2.

V2 in 2010? :)

one more vote... :`(

Please fix it. It really is annoying.

Uhh,

just discovered this - holding > 4 million user ids (from the search API) in my 
database. (twopular.com). I exclusively use the Search API so for that matter no 
issue right now. Yet as I learn from the V2 roadmap that the API's will merge so that 
they "use same User IDs". Yet which one will become the valid one? If the one from 
the REST API how will I get my 4 million users id's mapped to the REST API ids?

As somebody mentioned above

>> I maintain a huge search_id <-> user_id mapping table internally

should I better start building this too or will twitter provide support for this.

Thanks for any clarification

martin

I just noticed the status on this is Invalid. Is that because its in V2 (2011?). 

I really wish Twitter would just make available a CSV file of the user ID mapping for
us to download and put into our databases to get started at least. 

The problem is that there is _no_ unique mapping ... when a user changes his nickname,  
his search API ID changes ! and it's twitter API ID stays the same ... even worse, if 
someone re-uses a old nickname, it will get the old search API ID of the other user ...

So a single search API ID can map to several twitter account ID
and a single twitter account ID can have several search API ID ...

so basically that means that holding search API ID's is anyway rather shaky - please 
twitter - we all love you - just communicate clearly if this is so and what is the 
best way to deal with it - if there is any

one way seems to be to offer a ID mapping csv file as suggested above including the 
past ones which became invalid having a flag indicating this

thanks for any further clarifications

martin

FYI: commenting on closed tickets does not alert anyone at Twitter. Email api AT twitter.com with updates so 
someone will see them.

In answer to the V2 question the twitter.com ID will be the one used when they are combined.

thanks for the info - just wrote an email 

If the follower_id routine and friends_id routines could return 5000 screen_names 
instead of the ids this would be a work around for many of us too.

"Applications will have to perform a screen name-based lookup with the users/show
method to get the correct user id if necessary".

Let's say that a user perform a search through my application and I use search api.
It returns 200 results and I need to know if the user that posted the tweet is
following or followed by the user using my app.

I would use 4 api calls to perform this: search (x2 pages), friends/ids, followers/ids.

With this issue, for each search result I should call the users/show method to get
the correct user id, to be compared with friends/followers. It makes 204 calls for
one user action.

With a limit of 150 api call per hour I am not able to complete the request for my
user. I think there is a serious problem here...

I guess a workaround might be calling the statuses/friends statuses/followers to get
screen names that can be compared with a search result but it is much more time and
bandwidth consuming, because there are a lot of information not really needed.

Please hurry up solving that issue.

+1 on the issue to be fixed. None of the twitter-based webapps I use, can search for my 
tweets since June 09 :( http://search.twitter.com/search?q=from%3Aceetee

For God sake this is still not fixed?? How are we suppose to properly integrate our
code if the API problems aren't fixed in a timely manner? This issue was reported Dec
24, 2008, we are now OCTOBER 2009!!! 

Wow.  

This should have been fixed on priority

GN

 Issue 1170  has been merged into this issue.