Hi @basdebruin, @anon29275264, @PluginGenie,
I’m responding to all of you here in one message 
In short, we’re implementing this change to align some discrepancies in our schema:
- Some IDs were
Int, while others wereID - In some cases, the input type and output type of the same field/argument were not aligned (i.e., the input was
Intand the output wasID) - Even though we used the
Inttype, the contents were above the 32-bit limit, making them out of compliance with the GraphQL specification
To solve this, we adopted the standard ID type defined by the GraphQL Schema (see docs here).
Candidly, there are some things we can’t commit to as we don’t know the way the platform or company will grow. The shape of our system might have to change at some point, so committing to no changes in specific lengths, formats, types is very difficult.
Here’s what I do know and can commit to:
- The
IDtype is dynamic. It take integers and strings when it’s an input argument. It ONLY returns strings. If your code expects an integer for an ID, change it to a string. - Since we changed some inputs from
InttoID, you don’t need to convert these to numbers since they now accept strings. - IDs should be treated as random alphanumeric strings, and shouldn’t be interpreted/parsed in any way. I know that many of our IDs are numerical, but don’t rely on that pattern. We don’t have a specific maximum ID length or a specific format that we can commit to.
- In 2023-10, every field/argument returning/accepting an identifier will be of type
ID. For example, column IDs are no longer strings. Their “format” will not change, but they will all be strings in responses. This should answer your first question (Cody) and your last question (Oliver).
Of course, if we change the type again in the future, we will treat it as a breaking change and will notify you all well in advance! No changes planned at the moment, but wanted to just clarify.
Let us know if you have any other questions