Passer au contenu
/
Basculer la limite de pré...

API Catalog (2.0.0)

Overview

  • Version: 2.0.0
  • Servers: https://store.xsolla.com/api
  • Contact Us by Email
  • Contact URL: https://xsolla.com/
  • Required TLS version: 1.2

The Catalog API allows you to configure a catalog of in-game items on the Xsolla side and display the catalog to users in your store.

The API allows you to manage the following catalog entities:

  • Virtual items — in-game items such as weapons, skins, boosters.
  • Virtual currency — virtual money used to purchase virtual goods.
  • Virtual currency packages — predefined bundles of virtual currency.
  • Bundles — combined packages of virtual items, currency, or game keys sold as a single SKU.
  • Game keys — keys for games and DLCs distributed via platforms like Steam or other DRM providers.
  • Groups — logical groupings for organizing and sorting items within the catalog.

API calls

The API is divided into the following groups:

  • Admin — calls for creating, updating, deleting, and configuring catalog items and groups. Authenticated via basic access authentication with your merchant or project credentials. Not intended for storefront use.
  • Catalog — calls for retrieving items and building custom storefronts for end users. Designed to handle high-load scenarios. Support optional user JWT authorization to return personalized data such as user-specific limits and active promotions.

Authentication

API calls require authentication either on behalf of a user or on behalf of a project. The authentication scheme used is specified in the Security section in the description of each call.

Authentication using user's JWT

User's JWT authentication is used when a request is sent from a browser, mobile application, or game. By default, the XsollaLoginUserJWT scheme is applied. For details on how to create a token, see the Xsolla Login API documentation.

The token is passed in the Authorization header in the following format: Authorization: Bearer <user_JWT>, where <user_JWT> is the user token. The token identifies the user and provides access to personalized data.

Vous pouvez également utiliser un jeton pour ouvrir l’interface de paiement.

Basic HTTP authentication

Basic HTTP authentication is used for server-to-server interactions, when an API call is sent directly from your server rather than from a user's browser or mobile application. HTTP Basic authentication with an API key is typically used.

Note

The API key is confidential and must not be stored or used in client applications.

With basic server-side authentication, all API requests must include the following header:

  • for basicAuth — Authorization: Basic <your_authorization_basic_key>, where your_authorization_basic_key is the project_id:api_key pair encoded in Base64
  • for basicMerchantAuth — Authorization: Basic <your_authorization_basic_key>, where your_authorization_basic_key is the merchant_id:api_key pair encoded in Base64

You can find the parameter values in Publisher Account:

  • merchant_id is displayed:
    • In Company settings > Company.
    • In the URL in the browser address bar on any Publisher Account page. The URL has the following format: https://publisher.xsolla.com/<merchant_id>.
  • project_id is displayed:
    • Next to the project name in Publisher Account.
    • In the URL in the browser address bar when working on a project in Publisher Account. The URL has the following format: https://publisher.xsolla.com/<merchant_id>/projects/<project_id>.
  • api_key is shown in Publisher Account only at the time of creation and must be stored securely on your side. You can create an API key in the following sections:
Notice

If a required API call doesn't include the project_id path parameter, use an API key that is valid across all company projects for authorization.

For more information about working with API keys, see the API references.

Authentication with guest access support

Le schéma d’authentification AuthForCart est utilisé pour les achats via le panier et prend en charge deux modes :

  1. Authentication with a user's JWT. The token is passed in the Authorization header in the following format: Authorization: Bearer <user_JWT>, where <user_JWT> is the user token. The token identifies the user and provides access to personalized data. Alternatively, you can use a token for opening the payment UI.

  2. Simplified mode without Authorization header. This mode is used only for unauthorized users and can be applied only for game key sales. Instead of a token, the request must include the following headers:

    • x-unauthorized-id with a request ID
    • x-user with the user's email address encoded in Base64

Core entity structure

Items of all types (virtual items, bundles, virtual currency, and keys) use a similar data structure. Understanding the basic structure simplifies working with the API and helps you navigate the documentation more easily.

Note

Some calls may include additional fields but they don't change the basic structure.

Identification

  • merchant_id — company ID in Publisher Account
  • project_id — project ID in Publisher Account
  • sku — item SKU, unique within the project

Store display

  • name — item name
  • description — item description
  • image_url — image URL
  • is_enabled — item availability
  • is_show_in_store — whether the item is displayed in the catalog

For more information about managing item availability in the catalog, see the documentation.

Organization

  • type — item type, for example, a virtual item (virtual_item) or bundle (bundle)
  • groups — groups the item belongs to
  • order — display order in the catalog

Sale conditions

  • prices — prices in real or virtual currency
  • limits — purchase limits
  • periods — availability periods
  • regions — regional restrictions

Example of core entity structure:

{
  "attributes": [],
  "bundle_type": "virtual_currency_package",
  "content": [
    {
      "description": {
        "en": "Main in-game currency"
      },
      "image_url": "https://.../image.png",
      "name": {
        "en": "Crystals",
        "de": "Kristalle"
      },
      "quantity": 500,
      "sku": "com.xsolla.crystal_2",
      "type": "virtual_currency"
    }
  ],
  "description": {
    "en": "Crystals x500"
  },
  "groups": [],
  "image_url": "https://.../image.png",
  "is_enabled": true,
  "is_free": false,
  "is_show_in_store": true,
  "limits": {
    "per_item": null,
    "per_user": null,
    "recurrent_schedule": null
  },
  "long_description": null,
  "media_list": [],
  "name": {
    "en": "Medium crystal pack"
  },
  "order": 1,
  "periods": [
    {
      "date_from": null,
      "date_until": "2020-08-11T20:00:00+03:00"
    }
  ],
  "prices": [
    {
      "amount": 20,
      "country_iso": "US",
      "currency": "USD",
      "is_default": true,
      "is_enabled": true
    }
  ],
  "regions": [],
  "sku": "com.xsolla.crystal_pack_2",
  "type": "bundle",
  "vc_prices": []
}

Basic purchase flow

The Xsolla API allows you to implement in-game store logic, including retrieving the item catalog, managing the cart, creating orders, and tracking their status. Depending on the integration scenario, API calls are divided into Admin and Catalog subsections, which use different authentication schemes.

The following example shows a basic flow for setting up and operating a store, from item creation to purchase.

Create items and groups (Admin)

Create an item catalog for your store, such as virtual items, bundles, or virtual currency.

Example API calls:

Set up promotions, chains, and limits (Admin)

Configure user acquisition and monetization tools, such as discounts, bonuses, daily rewards, or offer chains.

Example API calls:

Get item information (Client)

Configure item display in your application.

Notice

Do not use API calls from the Admin subsection to build a user catalog. These API calls have rate limits and aren't intended for user traffic.

Example API calls:

Note

By default, catalog API calls return items that are currently available in the store at the time of the request. To retrieve items that are not yet available or are no longer available, include the parameter "show_inactive_time_limited_items": 1 in the catalog request.

Sell items

You can sell items using the following methods:

  • Fast purchase — sell one SKU multiple times.
  • Cart purchase — the user adds items to the cart, removes items, and updates quantities within a single order.

If an item is purchased using virtual currency instead of real money, use the Create order with specified item purchased by virtual currency API call. The payment UI is not required, as the charge is processed when the API call is executed.

For free item purchase, use the Create order with specified free item API call or the Create order with free cart API call. The payment UI is not required — the order is immediately set to the done status.

Fast purchase

Use the client-side API call to create an order with a specified item. The call returns a token used to open the payment UI.

Note

Discount information is available to the user only in the payment UI. Promo codes are not supported.

Cart purchase

Cart setup and purchase can be performed on the client or on the server side.

Set up and purchase a cart on the client

Implement the logic of adding and removing items by yourself. Before calling the API for setting up a cart, you will not have information about which promotions will be applied to the purchase. This means that the total cost and details of the added bonus items will not be known.

Implement the following cart logic:

  1. After the player has filled a cart, use the Fill cart with items API call. The call returns the current information about the selected items (prices before and after discounts, bonus items).
  2. Update the cart contents based on user actions:
Note

To get the current status of the cart, use the Get current user's cart API call.
  1. Use the Create order with all items from current cart API call. The call returns the order ID and payment token. The newly created order is set to new status by default.

Set up and purchase a cart on the server

This setup option may take longer for setting the cart up, since each change to the cart must be accompanied by API calls.

Implement the following cart logic:

  1. After the player has filled a cart, use the Fill cart with items API call. The call returns current information about the selected items (prices before and after discounts, bonus items).
  2. Use the Create order with all items from current cart API call. The call returns the order ID and payment token. The newly created order is set to new status by default.

Open payment UI

Use the returned token to open the payment UI in a new window. Other ways to open the payment UI are described in the documentation.

ActionEndpoint
Open in production environment.https://secure.xsolla.com/paystation4/?token={token}
Open in sandbox mode.https://sandbox-secure.xsolla.com/paystation4/?token={token}
Note

Use sandbox mode during development and testing. Test purchases don't charge real accounts. You can use test bank cards.

After the first real payment is made, a strict sandbox payment policy takes effect. A payment in sandbox mode is available only to users specified in Publisher Account > Company settings > Users.

Buying virtual currency and items for real currency is possible only after signing a license agreement with Xsolla. To do this, in Publisher Account, go to Agreements & Taxes > Agreements, complete the agreement form, and wait for confirmation. It may take up to 3 business days to review the agreement.

To enable or disable sandbox mode, change the value of the sandbox parameter in the request for fast purchase and cart purchase. Sandbox mode is off by default.

Possible order statuses:

  • new — order created
  • paid — payment received
  • done — item delivered
  • canceled — order canceled
  • expired — order expired

Track order status using one of the following methods:

Pagination

API calls that return large sets of records (for example, when building a catalog) return data in pages. Pagination is a mechanism that limits the number of items returned in a single API response and allows you to retrieve subsequent pages sequentially.

Use the following parameters to control the number of returned items:

  • limit — number of items per page
  • offset — index of the first item on the page (numbering starts from 0)
  • has_more — indicates whether another page is available
  • total_items_count — total number of items

Example request:

GET /items?limit=20&offset=40

Response example:

{
  "items": [...],
  "has_more": true,
  "total_items_count": 135
}

It is recommended to send subsequent requests until the response returns has_more = false.

Date and time format

Dates and time values are passed in the ISO 8601 format.

The following are supported:

  • UTC offset
  • null value when there is no time restriction for displaying an item
  • Unix timestamp (in seconds) used in some fields

Format: YYYY-MM-DDTHH:MM:SS±HH:MM

Example: 2026-03-16T10:00:00+03:00

Localization

Xsolla supports localization of user-facing fields such as item name and description. Localized values are passed as an object where the language code is used as the key. The full list of supported languages is available in the documentation.

Supported fields

Localization can be specified for the following parameters:

  • name
  • description
  • long_description

Locale format

The locale key can be specified in one of the following formats:

  • Two-letter language code: en, ru
  • Five-letter language code: en-US, ru-RU, de-DE

Examples

Example with a two-letter language code:

{
  "name": {
    "en": "Starter Pack",
    "ru": "Стартовый набор"
  }
}

Example with a five-letter language code:

{
  "description": {
    "en-US": "Premium bundle",
    "de-DE": "Premium-Paket"
  }
}

Country and currency determination

The user's country determines catalog prices, the payment currency, and available payment methods in the payment UI. Depending on the API call, the country is determined as follows:

  • In client-side API calls, the country is determined by the IP address of the request.
  • In server-side API calls, the country is determined by the value of the user.country.value parameter or by the user's IP address from the X-User-Ip header. If both are passed, the user.country.value parameter takes precedence.
Note

Only IPv4 addresses are supported for country determination. Passing an IPv6 address may result in incorrect country and currency detection. If you use the server-side API call and cannot provide the user's IPv4 address, pass the country in the user.country.value parameter.

Error response format

If an error occurs, the API returns an HTTP status and a JSON response body. The full list of store-related errors is available in the documentation.

Response example:

{
  "errorCode": 1102,
  "errorMessage": "Validation error",
  "statusCode": 422,
  "transactionId": "c9e1a..."
}
  • errorCode — error code.
  • errorMessage — short error description.
  • statusCode — HTTP response status.
  • transactionId — request ID. Returned only in some cases.
  • errorMessageExtended — additional error details, such as request parameters. Returned only in some cases.

Extended response example:

{
  "errorCode": 7001,
  "errorMessage": "Chain not found",
  "errorMessageExtended": {
    "chain_id": "test_chain_id",
    "project_id": "test_project_id",
    "step_number": 2
  },
  "statusCode": 404
}

Common HTTP status codes

  • 400 — invalid request
  • 401 — authentication error
  • 403 — insufficient permissions
  • 404 — resource not found
  • 422 — validation error
  • 429 — rate limit exceeded

Recommendations

  • Handle the HTTP status and the response body together.
  • Use errorCode to process errors related to application logic.
  • Use transactionId to identify requests more quickly when analyzing errors.
Télécharger la description d'OpenAPI
index.json
index.yaml
Langues
Serveurs
https://store.xsolla.com/api/
Mock server
https://xsolla.redocly.app/_mock/fr/api/catalog/

Aperçu

Vous pouvez utiliser des objets virtuels et de la monnaie virtuelle pour créer un magasin en jeu et configurer son affichage pour les utilisateurs. Les types d'objets suivants sont disponibles :

  • Objets virtuels — biens en jeu tels que des armes, des skins ou des boosters. Peuvent être vendus contre des devises réelles ou de la monnaie virtuelle.
  • Monnaie virtuelle — monnaie en jeu utilisée pour acheter des objets virtuels. Peut être vendue contre des devises réelles ou de la monnaie virtuelle.
  • Packages de monnaie virtuelle — quantité fixe de monnaie virtuelle. Peuvent être vendus contre des devises réelles ou de la monnaie virtuelle.

Les groupes sont utilisés pour organiser les objets dans le catalogue. Ils vous permettent de regrouper logiquement les objets et de gérer leur affichage.

Utilisez les appels API de la sous-section Administrateur pour créer, modifier et supprimer des objets.

Utilisez les appels API de la sous-section Catalogue pour récupérer des listes d'objets et les afficher aux utilisateurs.

Note

N'utilisez pas les appels API de la sous-section Administrateur pour créer un catalogue de magasin.

Note

L'appel API Lire la liste des objets virtuels renvoie des données détaillées sur les objets, y compris les prix et les attributs, et prend en charge la pagination. Utilisez-le pour afficher les pages du catalogue dans la vitrine.

L'appel API Lire la liste de tous les objets virtuels renvoie l'UGS, le nom, la description des objets, ainsi que l'ID et le nom du groupe sans pagination. Utilisez-le pour la recherche côté client ou l'indexation.

Pour les achats avec de la monnaie virtuelle, utilisez l'appel API Créer une commande à partir d'un objet spécifique en monnaie virtuelle. L'interface de paiement n'est pas requise, le coût est traité lors de l'exécution de l'appel API.

Exemple de processus d'achat avec de la monnaie virtuelle :

Exemple de processus d'achat avec de la monnaie virtuelle

Administrateur

Opérations

Catalogue

Opérations

Paiement virtuel

Opérations

Aperçu

Les clés de jeu sont des codes alphanumériques uniques à usage unique permettant d’accéder à un jeu ou à un contenu téléchargeable (DLC) sur les plateformes de jeux vidéo. Vous pouvez vendre des clés de jeu via un lien direct, via l'interface du magasin, ou via un widget. Vous pouvez également configurer des restrictions régionales afin de vendre les clés de jeu dans des pays spécifiques. Pour plus d'informations, consultez la section Packs de clés de jeux.

L'authentification utilisateur n'est pas requise pour vendre des clés de jeu : elles sont envoyées à l'adresse e-mail fournie lors du paiement. Vous pouvez toutefois la configurer pour accéder à des fonctionnalités comme la personnalisation, les limites d'achat ou le système des droits. Pour en savoir plus, consultez la section Comment configurer l'authentification pour la vente de clés de jeu.

Flux de vente de clés de jeux :

  1. Créez un jeu en utilisant l'appel API Créer un jeu.
  2. Configurez les restrictions régionales.
  3. Téléchargez des clés dans un package de clés de jeu en utilisant l'appel API Télécharger des codes afin de les proposer à la vente.
  4. Affichez le catalogue des jeux avec les prix correspondant à la région de l'utilisateur à l'aide de l'appel API Lire la liste des jeux.
  5. Créez une commande. Pour un achat rapide, utilisez l'appel API Créer une commande à partir de tous les objets du panier actuel, en passant l'UGS de la clé de jeu. La réponse renvoie un jeton permettant d'ouvrir l'interface de paiement.
  6. Implémentez l'ouverture de l'interface de paiement afin de régler la commande.

Pour recevoir des notifications en temps réel sur les paiements réussis et l'attribution des objets à l'utilisateur, configurez le suivi du statut des commandes, par exemple via les webhooks. Les clés sont envoyées à l'adresse e-mail indiquée lors du paiement, et la commande passe au statut done.

Clés de jeu

Catalogue

Opérations

Droit

Opérations

Administrateur

Opérations

Aperçu

Les lots sont des ensembles d'objets vendus comme une seule unité. Un lot peut inclure des objets virtuels, de la monnaie virtuelle, des packages de monnaie virtuelle, des clés de jeu et d'autres lots. Utilisez les lots pour créer des kits de démarrage, des offres saisonnières et des offres spéciales.

Utilisez les groupes d'appels API suivants pour interagir avec les lots :

  • Utilisez des appels API de la sous-section Administrateur pour créer, mettre à jour, supprimer des lots, et gérer leur visibilité.
  • Utilisez des appels API de la sous-section Catalogue pour récupérer des lots.

Les limites d'achat sont configurées via l'objet limits lors de la création ou de la mise à jour d'un lot. Pour en savoir plus, consultez l'aperçu des Limites. Vous pouvez également configurer des restrictions régionales afin de vendre des objets dans des pays spécifiques.

Note

Pour en savoir plus sur la configuration des lots, consultez la section Lots.

Scénario de gestion de lot :

  1. Créez un lot en utilisant l'appel API Créer un lot. Pour vérifier le lot créé, utilisez l'appel API Lire un lot. Pour récupérer tous les lots du projet, utilisez l'appel API Lire la liste des lots.
  2. Si nécessaire, utilisez l'appel API Mettre à jour un lot pour modifier le contenu ou les paramètres du lot.
  3. Implémentez la logique d'affichage des lots dans votre vitrine en utilisant l'appel API Lire la liste des lots, Lire un lot spécifique, ou Lire la liste des lots par groupe spécifique.
  4. Créez une commande en utilisant la section Panier et paiement. Par exemple, pour un achat rapide, vous pouvez utiliser l'appel API Créer une commande à partir d'un objet spécifique, en passant l'UGS du lot. La réponse contient un jeton pour ouvrir l'interface de paiement.
  5. Implémentez l'ouverture de l'interface de paiement pour payer la commande.
  6. Configurez le suivi du statut de la commande, par exemple en utilisant des webhooks, pour recevoir rapidement des données sur les objets payés avec succès et les attribuer à l'utilisateur.

Scénario de gestion de lot

Administrateur

Opérations

Catalogue

Opérations

Aperçu

Le panier est un mécanisme d'achat qui permet de regrouper plusieurs objets dans une seule commande. Un utilisateur peut acheter des objets de tout type et en toute quantité avec de la devise réelle, ainsi qu'utiliser des codes promo.

Le panier est stocké côté Xsolla. Sa sauvegarde d'une session à une autre dépend de l'authentification :

  • pour les utilisateurs authentifiés, le panier est lié à un utilisateur et conservé entre les sessions tant que les requêtes sont effectuées au nom de ce même utilisateur.

  • Pour les utilisateurs non authentifiés, la sauvegarde du panier dépend de la transmission de l'en-tête x-unauthorized-id. Pour conserver le panier d'un utilisateur non authentifié d'une session à l'autre, passez le même x-unauthorized-id dans chaque requête. Cette option est disponible uniquement pour la vente de clés de jeu.

Vous pouvez identifier le panier de deux façons : automatiquement via le JWT utilisateur ou via l'ID du panier (cart_id).

La gestion du panier est disponible à la fois côté client et côté serveur.

Côté serveur, vous pouvez remplir le panier avec des objets, par exemple lors de la restauration d'une session utilisateur. Les actions suivantes sont disponibles côté client :

  • récupérer le panier de l'utilisateur actuel ou un panier par ID
  • remplir le panier
  • mettre à jour les objets dans le panier
  • supprimer des objets du panier

Pour acheter des objets du panier, les appels client et serveur servent à créer une commande.

La durée de vie (TTL) du panier est de 72 heures par défaut. Si son contenu change, par exemple lorsqu'un nouvel objet est ajouté, la TTL est prolongée.

Après un paiement réussi, le panier n'est pas vidé automatiquement. Pour le vider, utilisez les appels API côté client suivants :

Scénario d'utilisation du panier :

  1. Implémentez une interface de magasin permettant à l'utilisateur de sélectionner des objets.

  2. Lorsque l'utilisateur sélectionne des objets dans le magasin, ajoutez-les au panier, par exemple via l'appel Remplir le panier d'objets. Dans le tableau des objets, indiquez les UGS et les quantités requises pour chaque objet.

  3. Implémentez l'interface du panier. Lors de l'accès au panier, affichez son contenu via l'appel Lire le panier de l'utilisateur actuel. La réponse inclut des informations sur le prix final de l'objet, avec remises et promotions appliquées.

  4. Implémentez l'ouverture de l'interface de paiement pour régler la commande. Vous pouvez, par exemple, utiliser l'appel Créer une commande à partir de tous les objets d'un panier spécifique. La réponse renvoie un jeton permettant d'ouvrir l'interface de paiement.

  5. Configurez le suivi du statut des commandes, par exemple à l'aide des webhooks, afin de recevoir rapidement les informations sur les objets payés avec succès et de les attribuer à l'utilisateur.

Note

Pour implémenter la vente d'objets en jeu et en ligne, consultez le guide d'intégration.

Flux de panier et de paiement

Cycle de vie d'une commande

Comprendre le cycle de vie d'une commande vous aide à suivre les commandes et à implémenter correctement la logique post-achat, par exemple l'attribution des objets.

La commande passe par les statuts suivants :

StatutDescriptionNotes
newCommande créée. Le système attend la confirmation du paiement..Les descriptions des statuts de transaction se trouvent dans la documentation Pay Station API.
paidCommande payée (la transaction est passée au statut done), et l'objet peut être attribué à l'utilisateur. La commande reste en statut new jusqu'à ce que le paiement soit confirmé.
doneObjet attribué à l'utilisateur. —
canceledPaiement remboursé. La commande passe à ce statut lorsque le statut de la transaction devient refunded.
expired La création d'une nouvelle commande pour un objet en édition limitée, un code promo ou une promotion fait passer toute commande antérieure non réglée contenant cet objet au statut expired. Seule la commande la plus récente peut être réglée. Si un utilisateur tente de régler une commande expirée, l'interface de paiement affichera une erreur 2002 et le paiement échouera.

Cycle de vie d'une commande

Note

Lorsque la commande passe au statut expired pendant que l'utilisateur finalise un paiement, mais que le paiement aboutit, la commande passe du statut expired au statut paid. Cela s'applique uniquement si la limite d'achat de l'objet associé à la commande n'est pas dépassée lors du paiement.

Panier (côté client)

Utilisez les appels de cette section pour gérer le panier côté client.

Opérations

Panier (côté serveur)

Utilisez les appels de cette section pour gérer le panier côté serveur.

Opérations

Paiement (côté client)

Utilisez les appels de cette section pour créer un jeton de paiement côté client.

Opérations

Paiement (côté serveur)

Utilisez les appels de cette section pour créer un jeton de paiement côté serveur.

Opérations

Commande

Utilisez les appels de cette section pour obtenir des informations sur les commandes.

Opérations

Biens gratuits

Use calls from this section to grant free items to users.

Opérations

Aperçu

Les limites d'achat vous permettent de restreindre la quantité d'objets disponibles à l'achat par un utilisateur unique ou par l'ensemble des utilisateurs. Vous pouvez également configurer des réinitialisations programmées des limites.

Les limites sont stockées côté Xsolla et sont configurées au niveau de l'objet individuel dans le Compte éditeur ou via l'objet limits dans les appels API suivants :

Les informations sur les limites sont renvoyées dans l'objet items.limits dans les appels API suivants pour récupérer le catalogue des objets :

Les appels API de la sous-section Gestion du groupe Limites vous permettent de récupérer l'état actuel des limites et de les mettre à jour pour un utilisateur spécifique, par exemple, réinitialiser le compteur après la fin d'une quête ou ajuster manuellement la quantité restante.

Note

Pour des informations détaillées sur la configuration des limites dans le catalogue, consultez la section Item purchase limits.

Gestion

Opérations

Administrateur

Opérations

Pré-commandes

Opérations

Supprimer une quantité de la limite de pré-commande pour un objetServer-sideAdmin

Requête

Supprime une quantité de la limite de pré-commande pour un objet.

L'API des limites de précommande vous permet de vendre un objet en quantité limitée. Pour configurer la pré-commande, accédez à la section Administrateur du module de l'objet souhaité :

Alias pour cet endpoint :

  • /v2/project/{project_id}/admin/items/pre_order/limit/item/id/{item_id}
Sécurité
basicAuth
Chemin
project_idintegerobligatoire

ID du projet. Vous trouverez ce paramètre dans le Compte éditeur, à côté du nom du projet, ainsi que dans l'URL affichée dans la barre d'adresse du navigateur lorsque vous utilisez ce projet. L'URL présente le format suivant : https://publisher.xsolla.com/<merchant_id>/projects/<project_id>.

Exemple: 44056
item_skustringobligatoire

UGS de l'objet.

Exemple: booster_mega_1
Corpsapplication/json
quantityintegerobligatoire

Quantity to remove.

curl -i -X DELETE \
  -u <username>:<password> \
  https://store.xsolla.com/api/v2/project/44056/admin/items/pre_order/limit/item/sku/booster_mega_1 \
  -H 'Content-Type: application/json' \
  -d '{
    "quantity": 100000
  }'

Réponses

La quantité de la limite a été supprimée avec succès.

Réponse
Aucun contenu

Basculer la limite de pré-commande pour un objetServer-sideAdmin

Requête

Activer/désactiver la limite de pré-commande de l'objet.

L'API des limites de précommande vous permet de vendre un objet en quantité limitée. Pour configurer la pré-commande, accédez à la section administrateur du module de l'objet souhaité :

Alias pour cet endpoint :

  • /v2/project/{project_id}/admin/items/pre_order/limit/item/id/{item_id}
Sécurité
basicAuth
Chemin
project_idintegerobligatoire

ID du projet. Vous trouverez ce paramètre dans le Compte éditeur, à côté du nom du projet, ainsi que dans l'URL affichée dans la barre d'adresse du navigateur lorsque vous utilisez ce projet. L'URL présente le format suivant : https://publisher.xsolla.com/<merchant_id>/projects/<project_id>.

Exemple: 44056
item_skustringobligatoire

UGS de l'objet.

Exemple: booster_mega_1
Corpsapplication/json
is_pre_order_limit_enabledbooleanobligatoire
curl -i -X PUT \
  -u <username>:<password> \
  https://store.xsolla.com/api/v2/project/44056/admin/items/pre_order/limit/item/sku/booster_mega_1/toggle \
  -H 'Content-Type: application/json' \
  -d '{
    "is_pre_order_limit_enabled": true
  }'

Réponses

La limite a été désactivée/activée.

Réponse
Aucun contenu

Supprimer toute la quantité de la limite de pré-commande pour un objetServer-sideAdmin

Requête

Supprime toute la quantité de limite de pré-commande pour un objet.

L'API des limites de précommande vous permet de vendre un objet en quantité limitée. Pour configurer la pré-commande, accédez à la section administrateur du module de l'objet souhaité :

Alias pour cet endpoint :

  • /v2/project/{project_id}/admin/items/pre_order/limit/item/id/{item_id}
Sécurité
basicAuth
Chemin
project_idintegerobligatoire

ID du projet. Vous trouverez ce paramètre dans le Compte éditeur, à côté du nom du projet, ainsi que dans l'URL affichée dans la barre d'adresse du navigateur lorsque vous utilisez ce projet. L'URL présente le format suivant : https://publisher.xsolla.com/<merchant_id>/projects/<project_id>.

Exemple: 44056
item_skustringobligatoire

UGS de l'objet.

Exemple: booster_mega_1
curl -i -X DELETE \
  -u <username>:<password> \
  https://store.xsolla.com/api/v2/project/44056/admin/items/pre_order/limit/item/sku/booster_mega_1/all

Réponses

La limite a été supprimée avec succès.

Réponse
Aucun contenu

Commerçant

Opérations

Catalogue

Cette API permet de récupérer tout type d'objet vendable ou tout objet spécifique.

Opérations

Régions communes

Les restrictions de vente régionales vous permettent de gérer la disponibilité des objets par pays ou groupes de pays. Par exemple, vous pouvez limiter la vente d'un jeu à certains pays en raison de contraintes de licence.

Les restrictions sont configurées par régions. Chaque région regroupe un ou plusieurs pays avec un identifiant region_id unique. Vous pouvez associer un objet à plusieurs régions.

La disponibilité des objets est déterminée comme suit :

  • Sans région spécifiée, un article est disponible à l'achat dans tous les pays.
  • Si le pays de l'utilisateur correspond à l'une des régions configurées, l'objet est disponible.
  • Si le pays de l'utilisateur ne correspond à aucune région configurée, l'article est indisponible.

Le pays de l'utilisateur est passé dans le paramètre country lors des requêtes au catalogue via les appels API de la sous-section Catalogue. Si ce paramètre n'est pas passé, le pays est déterminé selon l'adresse IP de l'utilisateur.

Le pays de l'utilisateur est vérifié par rapport aux régions associées à l'objet à deux étapes : lors des requêtes au catalogue et lors de la création d'une commande. Les objets indisponibles ne sont pas inclus dans la réponse du catalogue, et aucune commande contenant un tel article ne sera créée.

Utilisez les appels API du groupe Régions communes pour créer, mettre à jour et supprimer des régions.

Flux de configuration des restrictions de vente régionales :

  1. Créez une région via l'appel API Créer une région en spécifiant les pays concernés. La réponse retourne un region_id nécessaire à l'étape suivante.
  2. Associez un objet virtuel à cette région en passant son region_id au tableau regions lors de la création ou de la mise à jour de l'objet.
  3. Affichez le catalogue via les appels API de la sous-section Catalogue, par exemple l'appel API Lire la liste des objets virtuels. Le pays de l'utilisateur est défini par le paramètre country ou par son adresse IP si ce paramètre est absent. Les objets indisponibles dans ce pays ne sont pas renvoyés dans le catalogue.
  4. Lorsqu'un utilisateur souhaite payer un objet ou un panier, créez une commande :

La réponse contient un jeton permettant d'ouvrir l'interface de paiement.

Remarque

Xsolla vérifie si le pays de l'utilisateur est inclus dans la région associée à l'objet. Si le pays n'est pas inclus dans la région de l'onjet, la commande ne peut pas être créée.

  1. Implémentez l'ouverture de l'interface de paiement pour payer la commande.

Régions communes

Opérations

Webhooks

Opérations

Administrateur

Opérations

Administrateur

Opérations

Catalogue

Opérations