The Twitter ID Shuffle: Text vs Numbers

If you use the Twitter API in your application, a recent announcement at the Twitter Development Talk Google Group could have a bearing on the stability of your Integration. It has to do with the way Twitter plans to enable the new ID generator. What were once numbers will become text, in order to get around a limit to the size of numbers that some JavaScript parsers can handle.

Matt Harris, Developer Advocate at Twitter announced important information about the SnowFlake service that Twitter planned to use to generate unique Tweet IDs. Just prior to launch, the transition had to be aborted and Twitter released a new plan that you should take careful look at, to ensure that your application that depends on Twitter--especially the Tweet IDs--does not break.

The reason for aborting the launch was the fact that the new Twitter IDs (64bit unsigned integers) via the Snowflake Service caused problems on languages like JavaScript that could not Parse greater than 53 bits successfully. Twitter has provided an interim solution by providing the string version of any ID when responding in the JSON format. If you are using the main Twitter API, as well as Streaming and Search APIs, the Status, User, Direct Message and Saved Search IDs will be returned as an integer and a string in JSON responses.

Twitter has provided a clear action plan to API users by asking them to immediately evaluate the JSON response mentioned in the post. The steps, which I reproduce from the post are given below:

  • If your code converts the ID successfully without losing accuracy you are
    OK but should consider converting to the _str versions of IDs as soon as
  • If your code has lost accuracy, convert your code to using the _str
    version immediately. If you do not do this your code will be unable to
    interact with the Twitter API reliably.
  • In some language parsers, the JSON may throw an exception when reading the
    ID value. If this happens in your parser you will need to 'pre-parse' the data, removing or replacing ID parameters with their _str versions.

String versions of the IDs will start appearing in the API responses by Friday. Then there are two key dates: November 4 is when the SnowFlake service will be turned on with approx. 41bit length of the Status IDs. And finally, November 26 is when the SnowFlake service will start delivering Status IDs greater than 53 bits in length.

API changes are extremely critical and with an entire ecosystem built around Twitter's APIs, any errors are bound to have a huge multiplier effect. By keeping the communication channels open, Twitter has definitely made it easier to understand what are the changes on their side and how you need to adapt to keep that popular app of yours running.