Important Search Changes: real user IDs & support for URL, media, hashtag entities

By ‎@kurrik‎
Friday, 7 October 2011

Hello Developers! I just want to say one word to you. Just one word. Are you listening?

Search.

Big things are happening in search. Big things. I’m very happy to announce that two long-awaited improvements to the Twitter Search API are finally in the process of being rolled out:

First, you may now use the include_entities=true parameter in search queries to include entities in search results. These entities will make it easier to identify URLs, media, and hashtags present in a search result. As a reminder, we will not be supporting mentions at this time. Please see this discussion for more information.

The second annoucement deals with our intent to switch the user IDs returned by the search API to consistently match those returned by every other Twitter API.

You may use the new with_twitter_user_id=true parameter for the /search API endpoint in order to opt-in to receiving the official Twitter user IDs. On Monday, November 7th, we will start returning the official user IDs by default.

We were excited to see many well-reasoned responses from the community around which migration strategy to use, and the feedback has helped guide our plans for the switchover. As a developer, you will have one month to make sure that any apps which rely on the search API can handle receiving official IDs. Based off of the community feedback, we expect that few apps will be seriously impacted by this change, since consumers of the search API typically use the screen_name parameter to look up user data from search responses.*

The with_twitter_user_id=true approach was the most popular of the 4 options proposed, and was also picked because it allows us to turn off the aging infrastructure which generates search user IDs. It also maintains the existing response format, instead of introducing fields which would need to be deprecated later on.

These changes bring the Search API two steps closer in line with the REST API, so we’re hopeful that you’re as excited by these changes as we were to implement them. Naturally, we still want to hear feedback, so please follow up in this discussion thread if you have any comments.

Cheers,
~Arne

* If you do wind up changing your code, this would be a good time to future-proof your user ID storage. Current best practices are to store a user ID as a 64 bit integer, or a string.