Перейти к содержимому
/
Обновление значения атриб...

Catalog API (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.

В качестве альтернативы вы можете использовать токен для открытия платежного интерфейса.

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

Для продажи корзины используется схема аутентификации AuthForCart, которая поддерживает два режима:

  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.
Скачать описание OpenAPI
index.json
index.yaml
Языки
Серверы
https://store.xsolla.com/api/
Mock server
https://xsolla.redocly.app/_mock/ru/api/catalog/

Основная информация

С помощью виртуальных предметов и валюты вы можете построить внутриигровой магазин и настроить его отображение пользователям. Доступны следующие типы товаров:

  • Виртуальные предметы — внутриигровые товары, например оружие, скины или бустеры. Продаются за реальные деньги или виртуальную валюту.
  • Виртуальная валюта — внутриигровая валюта для покупки виртуальных предметов. Продается за реальные деньги или виртуальную валюту.
  • Пакеты виртуальной валюты — фиксированное количество виртуальной валюты. Продается за реальные деньги или виртуальную валюту.

Для организации товаров в каталоге используются группы. Они позволяют логически объединять товары и управлять их отображением.

Используйте методы подраздела Admin для создания, обновления и удаления товаров.

Используйте методы подраздела Catalog для получения списков товаров и их отображения пользователям.

Уведомление

Не используйте методы подраздела Admin для построения каталога пользователям.

Примечание

Метод Получение списка виртуальных предметов возвращает подробные данные о предметах, включая цены и атрибуты, и поддерживает пагинацию — используйте его для отображения страниц каталога в витрине магазина.

Метод Получение списка всех виртуальных предметов возвращает артикул, название и описание предмета, а также ID и название группы без пагинации — используйте его для поиска или индексирования на стороне клиента.

Для реализации покупок за виртуальную валюту используйте метод Создание заказа с указанным товаром, приобретенным за виртуальную валюту. Открывать платежный интерфейс не нужно — списание происходит в момент вызова метода.

Пример сценария покупки товара за виртуальную валюту:

Пример процесса покупки с использованием виртуальной валюты

Admin

Операции

Catalog

Операции

Виртуальная оплата

Операции

Основная информация

Игровые ключи — это разовые уникальные буквенно‑цифровые коды, которые дают пользователю доступ к игре или DLC на игровых платформах. Продажа игровых ключей возможна по прямой ссылке, через интерфейс магазина или через виджет. Вы также можете настроить региональные ограничения, чтобы продавать игровые ключи в определенных странах. Подробная информация об игровых ключах доступна в разделе Пакеты игровых ключей.

Для продажи игровых ключей аутентификация пользователей не требуется — ключи отправляются пользователю на указанный при покупке email-адрес. Настройка аутентификации обязательна, чтобы реализовать дополнительные сценарии: настроить персонализацию, ограничения на покупку или систему владения играми. Подробная информация доступна в разделе Как настроить аутентификацию для продажи игровых ключей.

Сценарий продажи игровых ключей:

  1. Создайте игру с помощью метода API Создание игры.
  2. Настройте региональные ограничения.
  3. Загрузите ключи в пакет игровых ключей с помощью метода API Загрузка кодов, чтобы продавать их пользователям.
  4. Отобразите пользователю каталог игр с ценами для его региона с помощью метода API Получение списка игр.
  5. Сформируйте заказ. Например, для быстрой покупки вы можете использовать метод API Создание заказа с указанным товаром, передав артикул игрового ключа. В ответе вы получите токен для открытия платежного интерфейса.
  6. Реализуйте открытие платежного интерфейса для оплаты заказа.

Настройте отслеживание статуса заказа, например с помощью вебхуков, чтобы своевременно получать данные об успешно оплаченных товарах и начислять их пользователю. Ключи отправляются пользователю на указанный при покупке email-адрес, после этого заказ переходит в статус done.

Игровые ключи

Catalog

Операции

Владение играми

Операции

Admin

Операции

Основная информация

Бандл — набор товаров, который продается как единое целое. В состав бандла можно добавить виртуальные предметы, виртуальную валюту, пакеты виртуальной валюты, игровые ключи и другие бандлы. Используйте бандлы для создания стартовых наборов, сезонных предложений и специальных предложений.

Используйте следующие группы методов API для работы с бандлами:

  • Admin — для создания, обновления, удаления бандлов и управления их видимостью.
  • Catalog — для получения списка бандлов.

Лимит на количество покупок настраивается с помощью объекта limits при создании или обновлении бандла. Подробная информация приведена в разделе Лимиты. Вы также можете настроить региональные ограничения, чтобы продавать товары в определенных странах.

Внимание

Подробная информация о настройке бандлов приведена в разделе Бандлы.

Сценарий работы с бандлами:

  1. Создайте бандл с помощью метода API Создание бандла. Чтобы проверить созданный бандл, используйте метод API Получение бандла. Чтобы получить список всех бандлов в проекте, используйте метод API Получение списка бандлов.
  2. При необходимости используйте метод API Обновление бандла для для изменения его состава или настроек.
  3. Реализуйте логику отображения бандлов в магазине с помощью методов API Получение списка бандлов, Получение указанного бандла или Получение списка бандлов по указанной группе.
  4. Сформируйте заказ, используя методы раздела Корзина и оплата. Например, для быстрой покупки вы можете использовать метод API Создание заказа с указанным товаром, передав артикул бандла. В ответе вы получите токен для открытия платежного интерфейса.
  5. Реализуйте открытие платежного интерфейса для оплаты заказа.
  6. Настройте отслеживание статуса заказа, например с помощью вебхуков, чтобы своевременно получать данные об успешно оплаченных товарах и начислять их пользователю.

Сценарий работы с бандлами:

Admin

Операции

Catalog

Операции

Основная информация

Корзина — это механизм покупки, который позволяет объединять несколько товаров в одном заказе. Пользователь может купить товары любого типа в любом количестве за реальную валюту, а также использовать промокоды.

Корзина хранится на стороне Xsolla. Сохранение корзины между сессиями зависит от того, авторизован ли пользователь:

  • Для авторизованных пользователей корзина привязана к конкретному пользователю и сохраняется между сессиями, пока запросы выполняются от имени того же пользователя.

  • Для неавторизованных пользователей сохранение корзины зависит от передачи заголовка x-unauthorized-id. Чтобы сохранить корзину неавторизованного пользователя между сессиями, передавайте один и тот же x-unauthorized-id в каждом запросе. Этот вариант доступен только при продаже игровых ключей.

Вы можете идентифицировать корзину двумя способами: автоматически по JWT пользователя или по ID корзины (cart_id).

Управление корзиной доступно как на стороне клиента, так и на стороне сервера.

На стороне сервера вы можете наполнить корзину товарами, например при восстановлении сессии пользователя. На стороне клиента доступны следующие действия:

  • получить корзину текущего пользователя или по ID корзины;
  • наполнить корзину;
  • обновить товары в корзине;
  • удалить товары из корзины.

Для оплаты товаров из корзины используются клиентские и серверные методы создания заказа.

По умолчанию время жизни корзины — 72 часа. Если состав корзины изменился, например при добавлении нового товара, ее время жизни продлевается.

После успешной оплаты корзина не очищается автоматически. Чтобы очистить корзину, используйте следующие клиентские методы API:

Сценарий использования корзины:

  1. Реализуйте интерфейс магазина, в котором пользователь будет выбирать товары.

  2. Когда пользователь выбирает товары в магазине, добавьте их в корзину, например с помощью метода Наполнение корзины товарами. В массиве items необходимо передать артикулы и количество необходимых товаров.

  3. Реализуйте интерфейс просмотра корзины. При переходе пользователя в корзину отобразите ее содержимое с помощью метода Получение корзины текущего пользователя. В ответе отобразится информация об итоговой цене товаров с учетом скидок, а также примененных акциях.

  4. Реализуйте открытие платежного интерфейса для оплаты заказа. Например, вы можете вызвать метод Создание заказа со всеми товарами из определенной корзины. В ответе вы получите токен для открытия платежного интерфейса.

  5. Настройте отслеживание статуса заказа, например с помощью вебхуков, чтобы своевременно получать данные об успешно оплаченных товарах и начислять их пользователю.

Примечание

Подробная информация о настройке продажи товаров в игре и онлайн приведена в руководстве по интеграции.

Сценарий использования корзины

Жизненный цикл заказа

Понимание жизненного цикла заказа поможет вам при настройке его отслеживания, например, чтобы начислить товары пользователю после успешной оплаты.

Заказ переходит по следующим статусам:

СтатусОписаниеПримечание
newЗаказ создан. Система ожидает подтверждение оплаты.Описания статусов транзакций приведены в документации Pay Station API.
paidЗаказ оплачен (транзакция перешла в статус done), и товар может быть начислен пользователю. Пока заказ не оплачен, он находится в статусе new.
doneТовар из заказа начислен пользователю. —
canceledПользователь оформил возврат платежа. Заказ переходит в этот статус, когда статус транзакции меняется на refunded.
expired Если новый заказ включает в себя товар, промокод или акцию, на которые настроены ограничения, предыдущий неоплаченный заказ с этим же товаром переходит в статус expired. Пользователь может оплатить только последний созданный заказ. Если пользователь пытается оплатить заказ, который находится в этом статусе, в платежном интерфейсе он увидит ошибку 2002 и не сможет совершить платеж.

Жизненный цикл заказа

Примечание

Если в процессе оплаты заказ перешел в статус expired, но пользователь успешно завершил платеж, заказ переходит из статуса expired в paid. Это возможно только если при оплате такого заказа не будет превышен лимит на покупку товара.

Корзина (на стороне клиента)

Используйте методы из этого подраздела для управления корзиной на стороне клиента.

Операции

Корзина (на стороне сервера)

Используйте методы из этого подраздела для управления корзиной на стороне сервера.

Операции

Оплата (на стороне клиента)

Используйте методы из этого подраздела для формирования платежного токена на стороне клиента.

Операции

Оплата (на стороне сервера)

Используйте методы из этого подраздела для формирования платежного токена на стороне сервера.

Операции

Заказ

Используйте методы из этого раздела для получения информации о заказах.

Операции

Бесплатные товары

Используйте методы из этого подраздела для начисления бесплатных товаров пользователям.

Операции

Основная информация

Лимиты на покупку ограничивают количество товаров, доступных одному пользователю или всем пользователям. Вы также можете задавать периоды автоматического обновления лимитов.

Лимиты хранятся на стороне Xsolla и задаются на уровне конкретного товара в Личном кабинете или через объект limits в следующих методах API:

Информация о лимитах возвращается в объекте items.limits в методах получения каталога товаров:

Методы подраздела Управление из группы методов Лимиты позволяют получать информацию о текущем состоянии лимитов и изменять их для конкретного пользователя — например, сбрасывать счетчик после выполнения квеста или корректировать остаток вручную.

Примечание

Подробная информация по настройке лимитов в каталоге приведена в разделе Лимиты на покупку товаров.

Управление

Операции

Admin

Операции

Предзаказы

Операции

Продавец

Операции

Catalog

Данный API позволяет получать продаваемые товары любого вида или конкретный товар.

Операции

Общие регионы

Региональные ограничения продаж позволяют управлять доступностью товаров в отдельных странах или группах стран. Например, можно продавать игру только в определенных странах из-за лицензионных ограничений.

Для настройки ограничений используются регионы. Каждый из них объединяет одну или несколько стран под одним идентификатором region_id. Товар может быть привязан к одному или нескольким регионам.

Доступность товара определяется следующим образом:

  • Если у товара не указаны регионы — он доступен для покупки во всех странах.
  • Если у товара указаны регионы, и страна пользователя входит в один из них — товар доступен для этого пользователя.
  • Если у товара указаны регионы, и страна пользователя не входит ни в один из них — товар недоступен для этого пользователя.

Страна пользователя передается в параметре country при запросе каталога через методы подраздела Catalog. Если параметр не передан, страна будет определена на основе IP-адреса пользователя.

Соответствие страны пользователя региону товара проверяется дважды: при запросе каталога и при создании заказа. Недоступные товары не попадают в ответ каталога, а заказ с таким товаром не будет создан.

Используйте методы группы Общие регионы для создания, изменения и удаления регионов.

Сценарий настройки региональных ограничений продаж:

  1. Создайте регион с помощью метода API Создание региона, указав список стран. Метод возвращает region_id, который понадобится на следующем шаге.
  2. Привяжите виртуальный товар к региону, передав его region_id в массиве regions при создании или обновлении товара.
  3. Отобразите пользователю каталог, используя методы подраздела Catalog, например с помощью метода API Получение списка виртуальных предметов. Страна пользователя определяется по параметру country, а если он не передан — по IP-адресу. Товары, недоступные в стране пользователя, не попадут в ответ каталога.
  4. При переходе пользователя к оплате товара или корзины сформируйте заказ:

В ответе вы получите токен для открытия платежного интерфейса.

Примечание

Xsolla проверяет, входит ли страна пользователя в регион, указанный у товара. Если страна не входит в регион товара, создание заказа будет недоступно.

  1. Реализуйте открытие платежного интерфейса для оплаты заказа.

Common regions

Операции

Вебхуки

Операции

Admin

Операции

Удаление всех значений атрибутаServer-sideAdmin

Запрос

Удаляет все значения атрибута.

Внимание

Если вы удалите значение атрибута, связь атрибута с товарами будет потеряна. Чтобы изменить значение атрибута для товара, используйте метод Обновление значения атрибута вместо удаления значения и создания нового.
Безопасность
basicAuth
Путь
project_idintegerобязательный

ID проекта. Вы можете найти этот параметр в Личном кабинете рядом с названием проекта, а также в адресной строке браузера при работе с проектом. URL-адрес имеет следующий формат: https://publisher.xsolla.com/<merchant_id>/projects/<project_id>.

Пример: 44056
external_idstringобязательный

External ID атрибута.

Пример: attribute_id
curl -i -X DELETE \
  -u <username>:<password> \
  https://store.xsolla.com/api/v2/project/44056/admin/attribute/attribute_id/value

Ответы

Значения атрибутов удалены успешно.

Ответ
Нет содержимого

Обновление значения атрибутаServer-sideAdmin

Запрос

Обновляет значения атрибута.

Безопасность
basicAuth
Путь
project_idintegerобязательный

ID проекта. Вы можете найти этот параметр в Личном кабинете рядом с названием проекта, а также в адресной строке браузера при работе с проектом. URL-адрес имеет следующий формат: https://publisher.xsolla.com/<merchant_id>/projects/<project_id>.

Пример: 44056
value_external_idstring^[-_\.\d\w]+$обязательный

External ID значения атрибута.

Пример: value_id
external_idstringобязательный

External ID атрибута.

Пример: attribute_id
Телоapplication/json
external_idstring[ 1 .. 255 ] characters^[-_.\d\w]+$обязательный

Уникальный ID значения атрибута. external_id может содержать только строчные латинские буквы, цифры, тире и подчеркивания.

Пример: "value_id"
valueobjectобязательный

Объект с локализациями для названия значения. Ключи для обозначения стран указаны в стандарте ISO 3166-1.

Пример: {"en":"Value","de":"Wert"}
value.​property name*stringдополнительное свойство
curl -i -X PUT \
  -u <username>:<password> \
  https://store.xsolla.com/api/v2/project/44056/admin/attribute/attribute_id/value/value_id \
  -H 'Content-Type: application/json' \
  -d '{
    "external_id": "weapon_class_sword_value",
    "value": {
      "en": "Sword",
      "de": "Schwert"
    }
  }'

Ответы

Значение атрибута обновлено успешно.

Ответ
Нет содержимого

Удаление значения атрибутаServer-sideAdmin

Запрос

Удаляет значение атрибута.

Внимание

Если вы удалите значение атрибута, связь атрибута с товарами будет потеряна. Чтобы изменить значение атрибута для товара, используйте метод Обновление значения атрибута вместо удаления значения и создания нового.
Безопасность
basicAuth
Путь
project_idintegerобязательный

ID проекта. Вы можете найти этот параметр в Личном кабинете рядом с названием проекта, а также в адресной строке браузера при работе с проектом. URL-адрес имеет следующий формат: https://publisher.xsolla.com/<merchant_id>/projects/<project_id>.

Пример: 44056
value_external_idstring^[-_\.\d\w]+$обязательный

External ID значения атрибута.

Пример: value_id
external_idstringобязательный

External ID атрибута.

Пример: attribute_id
curl -i -X DELETE \
  -u <username>:<password> \
  https://store.xsolla.com/api/v2/project/44056/admin/attribute/attribute_id/value/value_id

Ответы

Значение атрибута удалено успешно.

Ответ
Нет содержимого

Admin

Операции

Catalog

Операции