@elonmusk that can be changed at any time, and a User ID like 44196397 that is permanent for the lifetime of the account. If you are building anything that stores or references X accounts - a database, a monitoring system, a CRM integration, an analytics pipeline - you need to work with User IDs, because they never change even when users rebrand their handle.
Sorsa API provides three utility endpoints for instant conversion between these formats. This page documents all three, explains when and why you need them, and includes code for batch conversion.
No-code option: For one-off conversions, use the free Sorsa ID Converter web tool. Paste a username, ID, or profile URL and get the result instantly, no API key required.
Why User IDs Matter
Usernames are human-readable but unreliable as identifiers. A user can change their handle from@old_name to @new_name at any time, and someone else can then claim @old_name. If your system stores usernames as primary keys, a single handle change breaks every reference to that account.
User IDs are 64-bit Snowflake integers assigned at account creation. They never change, cannot be transferred, and are unique across the entire platform. Building your data layer around User IDs means:
- Handle changes do not break your system. Your database still points to the same account regardless of how many times they rename.
- Database performance improves. Integer indexing is faster and more storage-efficient than variable-length strings.
- Cross-referencing is reliable. When matching accounts across datasets, exports, or API responses from different time periods, IDs are the only stable join key.
- Some Sorsa endpoints accept only IDs. Endpoints like
/info-batchacceptuser_ids, and several community/list endpoints reference accounts by numeric ID. Having IDs on hand avoids extra conversion calls.
Endpoint 1: Username to User ID
Example
Python
JavaScript
Endpoint 2: User ID to Username
Example
Python
Endpoint 3: Profile Link to User ID
Example
Python
Batch Conversion: Usernames to IDs
When you have a list of handles (from a spreadsheet, a CRM export, or a competitor list) and need to convert them all to IDs for storage:Batch Conversion: IDs to Current Usernames
The reverse operation - resolving a list of stored IDs back to current handles. Useful for refreshing your database after accounts may have renamed:Common Patterns
Detecting Handle Changes
If you store both the User ID and the username at the time of collection, you can periodically re-resolve the IDs and detect renames:Normalizing Mixed Input
When users submit account references in different formats (some as handles, some as URLs, some as IDs), normalize everything to User IDs:Next Steps
- Followers and Following - many workflows start with ID conversion, then proceed to follower extraction.
- User Profile Data - use the
/infoendpoint with a User ID to get the full profile. - Audience Geography - the
/aboutendpoint also acceptsuser_idas input. - API Reference - full specification for
/username-to-id,/id-to-username,/link-to-id, and all 38 endpoints.