For a variety of reasons, the numbers used to identify accounts via Twitter’s API grow faster than the actual number of accounts in the system. Currently, user IDs fit in 32 bits—a standard size for integers on many platforms. In January, we explained that the current pace of Twitter user ID allocation meant that we’d exceed 32 bits sometime this year. All developers should make sure their code will handle the switch.
To help you update your code to use handle these bigger IDs, we’ve created two test accounts with large IDs: @64Flavors (ID: 4503597479886593) and @Overflow64 (ID: 4503599627370241). They’ve been set up to Tweet every 10 minutes, generating experimental data for both the REST and Streaming APIs.
Keep in mind that the kinds of errors to look out for are “silent killers”. Typically, a large ID number will be silently transformed into a negative number or even the ID of a completely different (but possibly valid) account as higher bits are dropped.
In the case of our test accounts, the generated IDs have been specifically allocated to avoid colliding with real accounts when truncated to 32 bits –– @Overflow64 truncates to -255 and @64Flavors truncates to 2147483393. Look for these numbers in databases or output by your code in order to determine dependency on 32-bit integers for handling user IDs.
We strongly recommend using the id_str version of IDs wherever available on any data type, including Tweets, users, direct messages and lists. The string versions of IDs take up more space but will work consistently on any platform, even those where developers cannot control the size of integer data types.
Please use this thread for any questions you may have about the migration to large user ID numbers.
Did someone say … cookies?