A service endpoint can change while the account identity remains the same. A player that remembers an old hostname or port may then fail before it can verify the current username and password. Use endpoint changes only when supplied through a verified service channel, and keep the previous value available for a reversible comparison.
Separate endpoint and credential changes
Changing every field at once makes it difficult to learn which value mattered. If support provides a new server address, update that field while preserving the current supplied credentials unless instructed otherwise.
Watch for impersonation
An unexpected message announcing a new server can be a way to collect credentials. Verify the change through a contact route you already trust rather than a number embedded in the message. Familiar branding alone does not authenticate the sender.
Update all intended profiles
A household may use several profiles or devices. Record which ones received the new endpoint and retire old backups after the replacement works. Avoid leaving two confusingly named profiles that look identical.
A practical sequence
- Verify the endpoint change independently.
- Update only the fields that actually changed.
- Record which profiles and backups need the new address.
An example
An old profile pointing at https://old.example.invalid can remain unusable even with the correct password if the service moved to a newly supplied endpoint.
Questions about this topic
Can I trust any message containing the logo?
No. Branding can be copied.
Should I guess an alternate hostname?
No. Use the endpoint supplied through verified support.
