This was an intentional change made in our database release v2026.04.13. This decision was made primarily because the Material and Task ID namespaces were becoming increasingly conflated - moving Materials to AlphaID creates a clear distinction between the two. Additionally, AlphaIDs are sortable, more memorable, and more easily extensible as identifiers.
To convert between the AlphaID (new format) and the Numeric ID (old format), it’s a base conversion from base-26 to base-10.
Some feedback from our users. They don’t like it =)
Couple of reasons:
Website itself and google still has numerical IDs (google Si) will get get URL with mp-149
Alphanumeric IDs are the same length so it is harder to spot things.
Will try to alleviate by providing also the old one (by conversion from base-26 to base-10). Since you mentioned it is extensible, it is now clear to me that it will work in the future (if this is guaranteed).
For #1 about urls + website: See the numbered list in that post and the bit that starts with Translating the comparisons above into URLs/queries:
TLDR is the backend will accept any id format you pass, even mixed formats, so URLs, Google search results, DOIs, etc. will always still resolve. The website also has user a profile option in the Dashboard to change how IDs are displayed across the website.
For #2 the REST API accepts an additional query parameter id_format to have the IDs formatted directly in the response from the server, see the final footer marked ***. Probably the most relevant for you as a dev.
This option hasn’t propagated to the mp-api client yet in a documented way. It can be passed as a kwarg to the internal _search function, but it’s not very ergonomic