Overview

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.

IP addresses

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

Download API definition

You can download the API definition in two formats:

YAML
JSON

Glossary

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.

Rate limits

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

Standard Login project

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

Shadow Login project

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

Main account

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.

Platform account

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.

Publishing platform

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

Authentication

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:

Authentication schemes

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.

Getting a user 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).

Getting a server token

To get a server token:

Set up server OAuth 2.0 client.
Generate server JWT.

Set up server OAuth 2.0 client

Open your project in Publisher Account and go to the Login section.
Click Configure in the panel of a Login project.
Go to the Security block and select the OAuth 2.0 section.
Click Add OAuth 2.0 Client.
Check the Server (server-to-server connection) box.
Specify Token lifetime.
Click Connect.
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.

Rate limits

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.

Note In certain cases, it is possible to adjust the rate limits by request. To request the rate limits adjustment, contact your Customer Success Manager or email csm@xsolla.com.

JWT structure

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

User JWT

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.

Main claims

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.

Claim	Type	Required	Description
`exp`	Unix Timestamp	Yes	Date and time of token expiration. Default expiration time is 24 hours. You can change expiration time for every Login project.
`iss`	string	Yes	Service that signed the token: `https://login.xsolla.com`.
`iat`	Unix Timestamp	Yes	Date and time of giving the token.
`sub`	string (UUID)	Yes	User ID written on the Xsolla Login server side.
`groups`	array	Yes	The list of groups the user is in. Every group is written in the following format: `id` — group ID `name` — group name `is_default` — shows whether the group is default or not (`true` or `false` values). There can be only one default group. This group initially includes all users before they are distributed into different groups.
`xsolla_login_project_id`	string (UUID)	Yes	Login project ID.
`type`	string		Authentication option: `xsolla_login` — login via username/email and password. `social` — social login `email` — passwordless login via one-time code received by email. `phone` — passwordless login via one-time code received by SMS. `firebase` — login via username/email and password when the user data storage is Firebase. `playfab` — login via username/email and password when the user data storage is PlayFab. `proxy` — login via username/email and password when the user data storage is custom. `device` — login with device ID. `server_custom_id` — login with custom ID. There can be only one default group. This group initially includes all users before they are distributed into different groups.
`avatar`	string		User avatar URL.
`username`	string		Username.
`publisher_id`	integer		ID of a merchant who owns a Login project.
`email`	string		User email address.
`payload`	string		Additional information that is passed in the payload parameter during authentication.
`promo_email_agreement`	boolean		May have one of the following values: `true` if the user agrees to receive a newsletter. `false` otherwise. Has the `true` value by default. To add the feature to the registration form of the Login widget: Contact your Account Manager if you use Widget 2.0. Add the `fields` parameter with the `promo_email_agreement` value to the initialization code if you use the previous version of the widget.
`connection_information`	string		Shows whether the user confirmed their birth date or not. Confirmation is made via the okname service.

PlayFab storage

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

Claim	Type	Required	Description
`external_account_id`	string	Yes	User PlayFab ID.
`session_ticket`	string	Yes	A SessionTicket parameter received during an authentication request or requests to the PlayFab API. A token contains the claim if you authenticate users via the OAuth 2.0 protocol and pass the `playfab` value to the `scope` parameter.
`entity_token`	string	Yes	An EntityToken.EntityToken parameter.
`entity_type`	string	Yes	An EntityToken.Entity.Type parameter. Can have only the `title_player_account` value.
`entity_id`	string	Yes	An EntityToken.Entity.Id parameter.

Custom storage

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

Claim	Type	Required	Description
`provider`	string	Yes	Name of a social network used for authentication. If the user authenticates via username and password, the claim has the `xsolla` value.
`external_account_id`	string		User ID on your server side.
`partner_data`			Data of any type returned by your server in the response body during authentication. To enable the transmission of this claim, contact your Customer Success Manager or email to csm@xsolla.com
`social_access_token`			Access token of the social network through which the user was authenticated. To enable the transmission of this claim, contact your Customer Success Manager or email to csm@xsolla.com.

Social authentication

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

Claim	Type	Required	Description
`provider`	string	Yes	Name of a social network used for authentication.
`id`	string	Yes	User ID in a social network.
`is_cross_auth`	boolean		Shows that the silent authentication request is in progress.
`social_access_token`	string		Social network account `access_token` parameter used for authentication. Contact your Account Manager to set up the feature.
`picture`	string (URL)		Link to the user profile picture in a social network.
`birthday`	date (RFC3339)		User birth date in a social network.
`gender`	string		User gender in a social network.
`name`	string		User nickname in a social network.

Authentication via the OAuth 2.0 protocol

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

Claim	Type	Required	Description
`jti`	string	Yes	Unique token ID.

Authentication via a phone number

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

Claim	Type	Required	Description
`phone_number`	string	Yes	User's phone number used for authentication. The phone number format based on the country code, area code, and line number without any dividers.

Server JWT

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.

Claim	Type	Required	Description
`xsolla_login_project_id`	string (UUID)	Yes	ID of a Login project that owns the OAuth 2.0 client.
`resources`	array	Yes	List of resources owned by a OAuth 2.0 client. Possible types of resources: `publisher_id` — resources of a merchant who owns the Login project `publisher_project_id` — resources of a project in Publisher Account. Every group is written in the following format: `name` — resource type `value` — resource ID
`jti`	string	Yes	Unique token ID.

JWT validation

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

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

Notice

Do not reveal your secret key to anyone. If it was compromised, please update it.

Errors

Refer to the documentation for information about Xsolla Login API errors.