How to Test Your Xtream Credentials

When a player fails to load content, the first question to resolve is whether the credentials themselves are valid. Testing your server address, username, and password independently before adjusting player settings or contacting support quickly isolates whether the problem lies with the credentials or with something further downstream.

Before You Test Your Credentials

Before testing, confirm you have all three components: the full server address including any port number, your username, and your password. A common source of errors is a copy-paste that drops the port, adds a trailing space, or captures an extra character. If your credentials were provided as a portal URL or a combined string, identify the three values within it before proceeding.

Check the Server Address First

Open the server address — host and port — in a browser without any API path attached. Some servers return a page or redirect at the root; others return a blank response or a connection error. A browser timeout or DNS resolution failure at this step means the server address itself is not reachable, which is a separate problem from incorrect credentials. An HTTP error code such as 403 suggests the server is running but restricting access to that path — continue to the next step, since the credential test uses a different path.

Test the Common Player API Response

https://HOST:PORT/player_api.php?username=USERNAME&password=PASSWORD

Replace HOST with your server domain or IP address, PORT with the port number issued with your credentials, USERNAME with your username, and PASSWORD with your password. Open the completed URL in a browser. Most servers that support this endpoint return a JSON response. If the browser prompts you to download a file rather than displaying text, open it in a text editor — the content is the same.

How to Read the Authentication Result

The response typically contains an account information section and a server information section. The account section may include fields indicating whether the credentials were accepted. Fields commonly observed across implementations include:

• auth — some servers include a field here where a value of 1 has been observed to signal an accepted result; this field is not guaranteed to be present and its type and meaning vary between implementations.
• status — values such as Active, Expired, and Disabled appear in some implementations; these are server-defined strings, not a universal standard.
• exp_date — where present, a Unix timestamp or date string indicating when the subscription expires according to the server.
• active_cons — where present, the number of streams currently using the account.

Not all of these fields will appear on every server, and additional fields are common. If the response is an HTTP error code rather than JSON, the meaning depends on the implementation — an HTTP error alone does not confirm whether credentials are valid or invalid. As rough guidance: a 401 response may indicate an authentication problem; a 403 response means the server refused the request, which can have application-level or permission causes beyond just wrong credentials; a 404 response may mean the expected API path is not present on that server; a 429 or 5xx response can reflect rate limiting or a server-side condition unrelated to credentials. Exact behaviour varies between implementations, so an HTTP error is a starting point for investigation rather than a definitive diagnosis.

When Credentials Work but Content Does Not

A response indicating accepted credentials confirms that the server recognised the account at that moment. It does not confirm that specific channels or categories are included in the subscription, that the subscription is currently active, or that the concurrent connection limit has not been reached. If credentials pass this test but the player shows no content or specific categories are missing, a basic username or password mistake becomes less likely as the cause. Missing content can still relate to account or content assignment, temporary server conditions, API implementation differences, player compatibility or parsing, or service configuration.

Test in a Player or Test the API Directly?

Testing against the player_api.php endpoint shows the raw server response and removes the player as a variable. Testing through a player adds the player's own connection logic, credential handling, and error reporting to the process. The direct endpoint test is most useful for confirming whether credentials are accepted at all; a player test reflects what the end user actually experiences.

If the direct endpoint returns an accepted result but the player shows an error, the next areas to check are player configuration, compatibility, and how the server exposes content to that player. Review the player's Xtream login fields and verify that each value is entered in the correct field rather than combined into a single URL.

Confirming that the server recognises the account is the most reliable first step because it eliminates the most fundamental variable. Once credentials are confirmed, player configuration, subscription scope, and content availability can each be addressed in sequence.