• Version: 1.0.0
• Servers: https://login.xsolla.com/api
• Protocols: https
• Accepts: application/json
• Responds with: application/json
• Contact us by email
• Contact URL: https://xsolla.com/

This section describes API calls for working with Login. Set up your Login project in Publisher Account before sending requests.

The full list of IP addresses that login.xsolla.com may use:

• 34.94.0.85
• 34.94.14.95
• 34.94.25.33
• 34.94.115.185
• 34.94.154.26
• 34.94.173.132
• 34.102.48.30
• 35.235.99.248
• 35.236.32.131
• 35.236.35.100
• 35.236.117.164

You can download the API definition in two formats:

• YAML
• JSON

You have access to the following Login project types in Publisher Account:

• Standard Login project
• Shadow Login project

To find more information on it, see Cross-platform account feature.

Are the restrictions applied by Xsolla API on the frequency of access by a user within a defined timeframe.

Is a Login project that is used to store main accounts.

Is a Login project that is used to store platform accounts.

Is an account type that is created in a standard Login project and linked to platform accounts. The main account is used to identify the player on different platforms.

Is an account type that is created in a shadow Login project and connected to a definite publishing platform. The platform account can’t be linked to another platform account. Also, you can’t unlink the accounts from a main account.

Is a game platform that is used for game distribution (e.g. Steam, PlayStation, Xbox, etc.).

Login API supports the following token types:

• User token. It is used for sending requests to the following user resources:
  • profile
  • friends
  • attributes
• Server token. It is used for sending requests to application resources such as settings or user data. The following requests are available:
  • Create platform accounts
  • Get user data
  • Link accounts
  • Link user accounts via external ID

You can determine whether an API call is client or server-side by the scheme of authentication:

• Client-side — are called without authentication or with the Authorization header: Bearer <user_JWT> header, where <user_JWT> — is the user token.
• Server-side API calls for implementing the user flow — are called with the header: X-SERVER-AUTHORIZATION: <server_JWT>, where <server_JWT> — is the server token.

To get the token, send one of the following requests:

• user registration (JWT or OAuth 2.0)
• authentication by username and password (JWT, OAuth 2.0, or JWT auth by username and password)
• authentication via social networks (JWT or OAuth 2.0)
• silent authentication (JWT or OAuth 2.0)
• authentication via a social network access token
• authentication via a publishing platform

After JWT authentication, the user is redirected to the Callback URL with a token in a query-parameter: <Callback URL>?token=<User token (JWT)>.

After OAuth 2.0 protocol-based authentication, send the Generate JWT request to the Xsolla Login server to exchange the received code parameter for a user token (access_token).

To get a server token:

1. Set up server OAuth 2.0 client.
2. Generate server JWT.

Set up server OAuth 2.0 client

1. Open your project in Publisher Account and go to the Login section.
2. Click Configure in the panel of a Login project.
3. Go to the Security block and select the OAuth 2.0 section.
4. Click Add OAuth 2.0 Client.
5. Check the Server (server-to-server connection) box.
6. Specify Token lifetime.
7. Click Connect.
8. Copy and save the client ID and secret key.

Generate server JWT

On the back end of your application, implement a method to get the server JWT using the Generate JWT API call. The request must contain the following parameters:

• grant_type is the type of getting JWT, pass the client_credentials value.
• client_secret is the secret key that is received when you set up the server OAuth 2.0 client.
• client_id is the client ID received when you set up the server OAuth 2.0 client.

To prevent Xsolla system overloads and protect against sudden spikes in incoming traffic, Xsolla limits the number of requests received by the Xsolla API within a specified period of time. If the limit is exceeded, the Xsolla API returns an HTTP response with the 429 status code.

Rate limits vary by method, IP-address, authentication scheme, and other factors.

Rate limits for server-side methods are applied to methods with server-side authentication — methods that are called with the X-SERVER-AUTHORIZATION: <server_JWT> header, where <server_JWT> is the server token.

Rate limits for client-side methods are applied to methods without authentication or with client-side authentication — methods that are called with the Authorization: Bearer <user_JWT> header, where <user_JWT> is the user token.

Example of a method with server-side authentication: Example of a method with client-side authentication:

Rate limits for client-side methods do not change and are necessary to prevent brute-force attacks. The maximum request rate for server-side methods is higher than for client-side methods. You can refer to the recommendations on how to manage rate limits in the documentation.

Every token has a JWT format and contains a definite information in a payload.

User JWT is a token received as a result of authentication or registration. A token payload contains information about the user and authentication call.

Getting a user token via the OAuth 2.0 protocol requires an OAuth 2.0 client. The user token is passed in the Authorization: Bearer <JWT> header.

A token will contain the main claims after authentication or email address confirmation. Presence of these claims does not depend on the user database and authentication call.

Claims that are contained in the token after authentication if you use PlayFab storage.

Claims that are contained in the token after authentication if you use custom storage.

Claims that are contained in the token after authentication via a social network. Presence of these claims does not depend on the user database.

Claims that are contained in the token after OAuth 2.0 authentication.

Claim which is contained in the token after authentication via a phone number.

The server token is passed in the X-SERVER-AUTHORIZATION header.

The token payload contains information about resources owned by the OAuth 2.0 client. The token has access to calls with server-based authentication for these resources.

To validate the JWT, use the following Login API calls:

• User JWT validate — for a user token.
• Server JWT validate — for a server token.

In case of error responses the Xsolla Login server returns a JSON object with the following fields:

{
  "error": {
    "code": "000-000",
    "description": "description"
  }
}