I have an idea for how this could potentially work: Time-based tokens.
The way I use time-based keys is with “steps” and “secrets”. The “step” is simply the floor of the current unix time divided by four (changes once every four seconds). The secret is a random string. In this case, I recommend the game ID be added onto the end of the secret.
To get the key, it would just be a hash of the current step with the secret shoved onto the end. This can then be reproduced on the server side, to see if it matches. (Note that the server side should also calculate for the previous step to see if it matches).
In this way, another endpoint can quickly verify whether a server is a teverse server or not, and you can keep secrets secure. The game ID added to the end will prevent a malicious developer from quickly grabbing the token and using it to make requests to other developer’s servers.
I don’t know how good this will actually work in production, but I use it in my personal projects and it seems to work very well.
(edit) Note that this solution only works if the teverse servers stay secure. Once the secret is leaked, it’s a free-for-all until it is changed.