商品目录API (2.0.0)
- 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.
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.
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.
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.
或者，您也可以使用用于打开支付UI的令牌。
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.
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>, whereyour_authorization_basic_keyis theproject_id:api_keypair encoded in Base64 - for
basicMerchantAuth—Authorization: Basic <your_authorization_basic_key>, whereyour_authorization_basic_keyis themerchant_id:api_keypair encoded in Base64
You can find the parameter values in Publisher Account:
merchant_idis 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_idis 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_keyis 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:
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.
AuthForCart身份认证方案用于购物车购买，支持两种模式：
Authentication with a user's JWT. The token is passed in the
Authorizationheader 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.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-idwith a request IDx-userwith the user's email address encoded in Base64
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.
Some calls may include additional fields but they don't change the basic structure.
Identification
merchant_id— company ID in Publisher Accountproject_id— project ID in Publisher Accountsku— item SKU, unique within the project
Store display
name— item namedescription— item descriptionimage_url— image URLis_enabled— item availabilityis_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 toorder— display order in the catalog
Sale conditions
prices— prices in real or virtual currencylimits— purchase limitsperiods— availability periodsregions— 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": []
}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 an item catalog for your store, such as virtual items, bundles, or virtual currency.
Example API calls:
Configure user acquisition and monetization tools, such as discounts, bonuses, daily rewards, or offer chains.
Example API calls:
Configure item display in your application.
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:
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.
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.
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.
Discount information is available to the user only in the payment UI. Promo codes are not supported.
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:
- 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).
- Update the cart contents based on user actions:
- To add an item or change item quantity, use the Update cart item by cart ID API call.
- To remove an item, use the Delete cart item by cart ID API call.
To get the current status of the cart, use the Get current user's cart API call.
- 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
newstatus 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:
- 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).
- 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
newstatus by default.
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.
| Action | Endpoint |
|---|---|
| Open in production environment. | https://secure.xsolla.com/paystation4/?token={token} |
| Open in sandbox mode. | https://sandbox-secure.xsolla.com/paystation4/?token={token} |
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 createdpaid— payment receiveddone— item deliveredcanceled— order canceledexpired— order expired
Track order status using one of the following methods:
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 pageoffset— index of the first item on the page (numbering starts from 0)has_more— indicates whether another page is availabletotal_items_count— total number of items
Example request:
GET /items?limit=20&offset=40Response example:
{
"items": [...],
"has_more": true,
"total_items_count": 135
}It is recommended to send subsequent requests until the response returns has_more = false.
Dates and time values are passed in the ISO 8601 format.
The following are supported:
- UTC offset
nullvalue 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
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:
namedescriptionlong_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"
}
}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.valueparameter or by the user's IP address from theX-User-Ipheader. If both are passed, theuser.country.valueparameter takes precedence.
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 request401— authentication error403— insufficient permissions404— resource not found422— validation error429— rate limit exceeded
Recommendations
- Handle the HTTP status and the response body together.
- Use
errorCodeto process errors related to application logic. - Use
transactionIdto identify requests more quickly when analyzing errors.
概述
您可以使用虚拟物品和虚拟货币构建游戏内购商店，并配置其向用户展示的方式。可使用以下商品类型：
- 虚拟物品 — 武器、皮肤、加成道具等游戏内商品。可使用真实货币或虚拟货币销售。
- 虚拟货币 — 用于购买虚拟物品的游戏内货币。可使用真实货币或虚拟货币销售。
- 虚拟货币套餐 — 固定数量的虚拟货币。可使用真实货币或虚拟货币销售。
组(Group)用于组织商品目录中的商品。通过组，您可以按逻辑对商品进行分组，并管理商品的显示方式。
使用管理子部分中的API调用来创建、更新和删除商品。
使用商品目录子部分中的API调用获取商品列表，并向用户展示商品。
请勿使用管理子部分中的API调用来构建商店商品目录。
获取虚拟物品列表API调用会返回详细的商品数据，包括价格和属性，并支持分页。请使用该调用在商店前端显示商品目录页面。
获取所有虚拟物品列表API调用会返回商品SKU、名称、描述，以及组ID和组名称，且不分页。请将其用于客户端侧搜索或索引。
如需使用虚拟货币的购买，请使用使用以虚拟货币购买的指定商品创建订单 API调用。无需支付UI⸺扣款会在执行API调用时完成。
使用虚拟货币购买流程示例：
项目ID。您可以在发布商帐户的项目名称旁找到此参数；使用项目时，也可以在浏览器地址栏中找到此参数。URL格式如下：https://publisher.xsolla.com/<merchant_id>/projects/<project_id>。
- https://store.xsolla.com/api/v2/project/{project_id}/admin/items/virtual_items/group/external_id/{external_id}
- Mock serverhttps://xsolla.redocly.app/_mock/zh/api/catalog/v2/project/{project_id}/admin/items/virtual_items/group/external_id/{external_id}
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X GET \
-u <username>:<password> \
'https://store.xsolla.com/api/v2/project/44056/admin/items/virtual_items/group/external_id/weapons?limit=50&offset=0'已成功收到虚拟物品列表。
属性列表。
唯一属性ID。 external_id只能包含大小写英文字母、数字、短横线和下划线。
包含属性本地化名称的对象。编码按照ISO 3166-1的规定。
包含商品本地化名称的对象。值接受以下两种格式之一：两个小写字母的语言代码（例如，en）或五个字符的语言代码（例如，en-US）。虽然两种格式都可作为输入接受，但响应会返回两个小写字母的语言代码。当为同一种语言提供了两种输入时（例如：en和en-US），将存储最后提供的值。您可以在文档中找到支持语言的完整列表。
两个小写字母的语言代码。
包含本地化商品描述的对象。值接受以下两种格式之一：两个小写字母的语言代码（例如，en）或五个字符的区域设置代码（例如，en-US）。虽然两种格式都可作为输入接受，但响应会返回两个小写字母的语言代码。当为同一种语言提供了两种输入时（例如：en和en-US），将存储最后提供的值。您可以在文档中找到支持语言的完整列表。
两个小写字母的语言代码。
包含商品详细本地化描述的对象。值接受以下两种格式之一：两个小写字母的语言代码（例如，en）或五个字符的区域设置代码（例如，en-US）。虽然两种格式都可作为输入接受，但响应会返回两个小写字母的语言代码。当为同一种语言提供了两种输入时（例如：en和en-US），将存储最后提供的值。您可以在文档中找到支持语言的完整列表。
两个小写字母的语言代码。
商品所属分组。
商品的附加资源，例如屏幕截图、游戏视频等。
符合ISO 3166-1 alpha-2标准的两位大写国家/地区代码。关于艾克索拉支持的国家/地区的详细信息，请参阅文档。
示例：country=US
图片URL。为确保图片能在支付UI中正确显示并快速加载，请查看我们的图片和URL指南：
- 支持的格式：WebP（推荐）、PNG、JPG。
- 文件大小：≤50 KB（WebP）或≤150 KB（PNG和JPG）。
- 图片尺寸：280 x 280 px。
- 色彩空间：sRGB。
- 协议：HTTPS，并对版本化URL使用长期缓存。
商品是否可购。如果为false，则无法在商店中购买该商品，也无法通过捆绑包或营销活动获得该商品。关于商品可购性的详细信息，请参阅我们的文档。
商品是否显示在商品目录中。如果为false且is_enabled: true，则该商品在商品目录中不可见，但可通过捆绑包或营销活动获得。关于商品可购性的详细信息，请参阅我们的文档。
商品可购区域的数组。如果数组为空或未传递，则该商品在所有区域均可购。
商品限制数。
单个用户的商品限制数。
设定商品在达到购买限制后、下次限制重置前在商品目录中的可见性。
适用于在recurrent_schedule数组中配置了周期性重置数量限制的商品。
如果未配置重置限制，则达到购买限制后，无论limit_exceeded_visibility的值如何，该商品都不会显示在商品目录中。
可能值：
show— 达到购买限制后，商品目录检索API调用仍会返回该商品。在客户端侧 商品目录检索API调用中，达到限制后返回的商品会带有can_be_bought: false标志。下一次重置日期 将在reset_next_date中返回。hide— 达到购买限制后，在限制 重置之前，商品目录检索API调用不会返回该商品。
全局商品限制数。
限制数刷新周期。
用户的限制数刷新周期。
用户限制数按每日刷新。
所需时区中的限制数刷新时间（四舍五入到小时）。
限制数刷新的日期和时间（Unix时间戳）。
第一次限制数刷新的日期和时间 (ISO 8601)。
商品销售期。
{ "items": [ { … }, { … }, { … }, { … } ] }
项目ID。您可以在发布商帐户的项目名称旁找到此参数；使用项目时，也可以在浏览器地址栏中找到此参数。URL格式如下：https://publisher.xsolla.com/<merchant_id>/projects/<project_id>。
- https://store.xsolla.com/api/v2/project/{project_id}/admin/items/virtual_items/group/id/{group_id}
- Mock serverhttps://xsolla.redocly.app/_mock/zh/api/catalog/v2/project/{project_id}/admin/items/virtual_items/group/id/{group_id}
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X GET \
-u <username>:<password> \
'https://store.xsolla.com/api/v2/project/44056/admin/items/virtual_items/group/id/10?limit=50&offset=0'已成功收到虚拟物品列表。
属性列表。
唯一属性ID。 external_id只能包含大小写英文字母、数字、短横线和下划线。
包含属性本地化名称的对象。编码按照ISO 3166-1的规定。
包含商品本地化名称的对象。值接受以下两种格式之一：两个小写字母的语言代码（例如，en）或五个字符的语言代码（例如，en-US）。虽然两种格式都可作为输入接受，但响应会返回两个小写字母的语言代码。当为同一种语言提供了两种输入时（例如：en和en-US），将存储最后提供的值。您可以在文档中找到支持语言的完整列表。
两个小写字母的语言代码。
包含本地化商品描述的对象。值接受以下两种格式之一：两个小写字母的语言代码（例如，en）或五个字符的区域设置代码（例如，en-US）。虽然两种格式都可作为输入接受，但响应会返回两个小写字母的语言代码。当为同一种语言提供了两种输入时（例如：en和en-US），将存储最后提供的值。您可以在文档中找到支持语言的完整列表。
两个小写字母的语言代码。
包含商品详细本地化描述的对象。值接受以下两种格式之一：两个小写字母的语言代码（例如，en）或五个字符的区域设置代码（例如，en-US）。虽然两种格式都可作为输入接受，但响应会返回两个小写字母的语言代码。当为同一种语言提供了两种输入时（例如：en和en-US），将存储最后提供的值。您可以在文档中找到支持语言的完整列表。
两个小写字母的语言代码。
商品所属分组。
商品的附加资源，例如屏幕截图、游戏视频等。
符合ISO 3166-1 alpha-2标准的两位大写国家/地区代码。关于艾克索拉支持的国家/地区的详细信息，请参阅文档。
示例：country=US
图片URL。为确保图片能在支付UI中正确显示并快速加载，请查看我们的图片和URL指南：
- 支持的格式：WebP（推荐）、PNG、JPG。
- 文件大小：≤50 KB（WebP）或≤150 KB（PNG和JPG）。
- 图片尺寸：280 x 280 px。
- 色彩空间：sRGB。
- 协议：HTTPS，并对版本化URL使用长期缓存。
商品是否可购。如果为false，则无法在商店中购买该商品，也无法通过捆绑包或营销活动获得该商品。关于商品可购性的详细信息，请参阅我们的文档。
商品是否显示在商品目录中。如果为false且is_enabled: true，则该商品在商品目录中不可见，但可通过捆绑包或营销活动获得。关于商品可购性的详细信息，请参阅我们的文档。
商品可购区域的数组。如果数组为空或未传递，则该商品在所有区域均可购。
商品限制数。
单个用户的商品限制数。
设定商品在达到购买限制后、下次限制重置前在商品目录中的可见性。
适用于在recurrent_schedule数组中配置了周期性重置数量限制的商品。
如果未配置重置限制，则达到购买限制后，无论limit_exceeded_visibility的值如何，该商品都不会显示在商品目录中。
可能值：
show— 达到购买限制后，商品目录检索API调用仍会返回该商品。在客户端侧 商品目录检索API调用中，达到限制后返回的商品会带有can_be_bought: false标志。下一次重置日期 将在reset_next_date中返回。hide— 达到购买限制后，在限制 重置之前，商品目录检索API调用不会返回该商品。
全局商品限制数。
限制数刷新周期。
用户的限制数刷新周期。
用户限制数按每日刷新。
所需时区中的限制数刷新时间（四舍五入到小时）。
限制数刷新的日期和时间（Unix时间戳）。
第一次限制数刷新的日期和时间 (ISO 8601)。
商品销售期。
{ "items": [ { … }, { … }, { … }, { … } ] }
项目ID。您可以在发布商帐户的项目名称旁找到此参数；使用项目时，也可以在浏览器地址栏中找到此参数。URL格式如下：https://publisher.xsolla.com/<merchant_id>/projects/<project_id>。
- https://store.xsolla.com/api/v2/project/{project_id}/admin/items/virtual_items/sku/{item_sku}
- Mock serverhttps://xsolla.redocly.app/_mock/zh/api/catalog/v2/project/{project_id}/admin/items/virtual_items/sku/{item_sku}
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X GET \
-u <username>:<password> \
https://store.xsolla.com/api/v2/project/44056/admin/items/virtual_items/sku/booster_mega_1已成功收到指定的虚拟物品。
属性列表。
唯一属性ID。 external_id只能包含大小写英文字母、数字、短横线和下划线。
包含属性本地化名称的对象。编码按照ISO 3166-1的规定。
包含商品本地化名称的对象。值接受以下两种格式之一：两个小写字母的语言代码（例如，en）或五个字符的语言代码（例如，en-US）。虽然两种格式都可作为输入接受，但响应会返回两个小写字母的语言代码。当为同一种语言提供了两种输入时（例如：en和en-US），将存储最后提供的值。您可以在文档中找到支持语言的完整列表。
两个小写字母的语言代码。
包含本地化商品描述的对象。值接受以下两种格式之一：两个小写字母的语言代码（例如，en）或五个字符的区域设置代码（例如，en-US）。虽然两种格式都可作为输入接受，但响应会返回两个小写字母的语言代码。当为同一种语言提供了两种输入时（例如：en和en-US），将存储最后提供的值。您可以在文档中找到支持语言的完整列表。
两个小写字母的语言代码。
包含商品详细本地化描述的对象。值接受以下两种格式之一：两个小写字母的语言代码（例如，en）或五个字符的区域设置代码（例如，en-US）。虽然两种格式都可作为输入接受，但响应会返回两个小写字母的语言代码。当为同一种语言提供了两种输入时（例如：en和en-US），将存储最后提供的值。您可以在文档中找到支持语言的完整列表。
两个小写字母的语言代码。
商品所属分组。
商品的附加资源，例如屏幕截图、游戏视频等。
符合ISO 3166-1 alpha-2标准的两位大写国家/地区代码。关于艾克索拉支持的国家/地区的详细信息，请参阅文档。
示例：country=US
图片URL。为确保图片能在支付UI中正确显示并快速加载，请查看我们的图片和URL指南：
- 支持的格式：WebP（推荐）、PNG、JPG。
- 文件大小：≤50 KB（WebP）或≤150 KB（PNG和JPG）。
- 图片尺寸：280 x 280 px。
- 色彩空间：sRGB。
- 协议：HTTPS，并对版本化URL使用长期缓存。
商品是否可购。如果为false，则无法在商店中购买该商品，也无法通过捆绑包或营销活动获得该商品。关于商品可购性的详细信息，请参阅我们的文档。
商品是否显示在商品目录中。如果为false且is_enabled: true，则该商品在商品目录中不可见，但可通过捆绑包或营销活动获得。关于商品可购性的详细信息，请参阅我们的文档。
商品可购区域的数组。如果数组为空或未传递，则该商品在所有区域均可购。
商品限制数。
单个用户的商品限制数。
设定商品在达到购买限制后、下次限制重置前在商品目录中的可见性。
适用于在recurrent_schedule数组中配置了周期性重置数量限制的商品。
如果未配置重置限制，则达到购买限制后，无论limit_exceeded_visibility的值如何，该商品都不会显示在商品目录中。
可能值：
show— 达到购买限制后，商品目录检索API调用仍会返回该商品。在客户端侧 商品目录检索API调用中，达到限制后返回的商品会带有can_be_bought: false标志。下一次重置日期 将在reset_next_date中返回。hide— 达到购买限制后，在限制 重置之前，商品目录检索API调用不会返回该商品。
全局商品限制数。
限制数刷新周期。
用户的限制数刷新周期。
用户限制数按每日刷新。
所需时区中的限制数刷新时间（四舍五入到小时）。
第一次限制数刷新的日期和时间 (ISO 8601)。
商品销售期。
{ "sku": "com.xsolla.swords_1", "name": { "en": "Sword Xsolla Skin" }, "type": "virtual_good", "description": { "en": "Honshu Boshin Wakizashi - Modern Tactical Samurai / Ninja Sword - Hand Forged 1060 Carbon Steel - Full Tang, Fully Functional, Battle Ready - Black TPR, Steel Guard and Pommel" }, "image_url": "https://cdn.xsolla.net/img/misc/images/8ab44fe99038a56de01950ba4a971b77.png", "long_description": { "en": "Honshu Boshin Wakizashi - Modern Tactical Samurai / Ninja Sword - Hand Forged 1060 Carbon Steel - Full Tang, Fully Functional, Battle Ready - Black TPR, Steel Guard and Pommel" }, "attributes": [ { … } ], "is_free": false, "is_paid_randomized_reward": true, "order": 1, "groups": [ { … }, { … } ], "prices": [ { … } ], "media_list": [], "vc_prices": [], "is_enabled": true, "is_show_in_store": true, "regions": [], "limits": { "per_user": { … }, "per_item": null, "recurrent_schedule": { … } }, "periods": [ { … } ], "custom_attributes": { "purchased": 0, "attr": "value" } }
概述
游戏Key是一次性使用的唯一字母数字代码，可授予用户在游戏平台上访问游戏或DLC的权限。您可以通过直接链接、商店UI或小组件销售游戏Key。您还可以配置区域限制，以便在特定国家/地区销售游戏Key。有关详细信息，请参阅游戏Key套餐部分。
销售游戏Key不要求用户身份认证——游戏Key会发送到用户在结算时指定的邮箱。您可以配置身份认证，以支持更多场景：个性化、购买限制或权益系统。有关详细信息，请参阅销售游戏Key时如何设置身份认证部分。
游戏Key销售流程：
- 使用创建游戏API调用创建游戏。
- 配置区域限制。
- 使用上传游戏Key API调用将游戏Key上传到游戏Key套餐，使其可供购买。
- 使用获取游戏列表API调用展示游戏目录，并显示适用于用户所在区域的价格。
- 创建订单。如需实现快速购买，可以使用使用当前购物车中的所有商品创建订单API调用，并传入游戏Key SKU。响应会返回用于打开支付UI的令牌。
- 实现支付UI的打开逻辑，以便用户支付订单。
如需及时接收支付成功通知并向用户交付商品，请设置订单状态跟踪，例如使用Webhook。游戏Key会发送到用户在结算时指定的邮箱，订单状态将变为done。
概述
捆绑包是作为一个单位销售的一组商品。捆绑包可以包含虚拟物品、虚拟货币、虚拟货币套餐、游戏Key以及其他捆绑包。您可以使用捆绑包创建新手礼包、季节性优惠和特惠活动。
如需实现捆绑包相关功能，请使用以下API调用组：
- 使用管理子部分中的API调用创建、更新、删除捆绑包，并管理其可见性。
- 使用商品目录子部分中的API调用获取捆绑包。
创建或更新捆绑包时，可通过limits对象配置购买限制。有关更多信息，请参阅限制概述。您还可以配置区域限制，以便在特定国家/地区销售商品。
捆绑包管理场景：
- 使用创建捆绑包API调用创建捆绑包。如需验证已创建的捆绑包，请使用获取捆绑包API调用。如需获取项目中的所有捆绑包，请使用获取捆绑包列表API调用。
- 如有需要，可使用更新捆绑包API调用修改捆绑包内容或设置。
- 使用获取捆绑包列表、获取指定的捆绑包或获取指定组的捆绑包列表API调用，在您的商店前端中实现捆绑包展示逻辑。
- 使用购物车与支付部分中的API创建订单。例如，如需实现快速购买，可以使用使用指定商品创建订单API调用，并传入捆绑包SKU。响应中包含用于打开支付UI的令牌。
- 实现支付UI的打开逻辑，以便用户支付订单。
- 设置订单状态跟踪，例如使用Webhook，以便及时接收支付成功商品的数据并向用户发放商品。
概述
购物车是一种购买机制，可将多个商品合并到同一个订单中。用户可以使用真实货币购买任意类型、任意数量的商品，也可以使用兑换码。
购物车存储在艾克索拉侧。购物车能否跨会话保存取决于用户是否已授权：
对于已授权用户，购物车会关联到具体用户。只要请求始终代表同一用户发送，购物车就会跨会话保存。
对于未授权用户，购物车能否保存取决于是否传入
x-unauthorized-id请求头。如需跨会话保存未授权用户的购物车，请在每个请求中传入相同的x-unauthorized-id。此选项仅适用于游戏Key销售。
您可以通过两种方式识别购物车：通过用户JWT自动识别或通过购物车ID (cart_id)识别。
可在客户端侧和服务器侧管理购物车。
在服务器侧，您可以向购物车添加商品，例如在恢复用户会话时。客户端侧支持以下操作：
- 获取当前用户的购物车或按ID获取购物车
- 向购物车添加商品
- 更新购物车中的商品
- 从购物车中删除商品
如需购买购物车中的商品，请使用客户端和服务器的订单创建调用。
购物车的存活时间（TTL）默认为72小时。如果购物车内容发生变化，例如添加了新商品，则TTL会延长。
支付成功后，购物车不会自动清空。如需清空购物车，请使用以下客户端侧API调用：
按购物车ID删除购物车商品和从当前购物车中删除购物车商品 — 删除购物车中的最后一件商品后，购物车即被清空。
购物车使用场景：
实现商店UI，供用户选择商品。
用户在商店中选择商品后，将商品添加到购物车，例如使用在购物车里添加商品调用。在items数组中，需要传入商品SKU和所需数量。
实现购物车查看UI。用户进入购物车时，使用获取当前用户的购物车调用展示购物车内容。响应将返回商品最终价格信息，包括折扣和已应用的促销活动。
实现支付UI的打开逻辑，以便用户支付订单。例如，可以使用使用特定购物车中的所有商品创建订单调用。响应会返回用于打开支付UI的令牌。
配置订单状态跟踪，例如使用Webhook，以便及时接收支付成功商品的数据并向用户发放商品。
注：
如需实现游戏内和线上商品销售，请参阅集成指南。
订单生命周期
了解订单生命周期有助于您跟踪订单，并正确实现购买后逻辑，例如商品交付。
订单会经历以下状态：
| 状态 | 描述 | 备注 |
new | 订单已创建。系统正在等待付款确认。 | 交易状态说明请参阅支付收银台API文档。 |
paid | 订单已支付（交易已流转至done状态），可以向用户发放商品。 | 在付款确认前，订单会保持new状态。 |
done | 商品已发放给用户。 | — |
canceled | 付款已退款。 | 当交易状态变更为refunded时，订单会流转至此状态。 |
expired | 对于限购商品、兑换码或促销活动，创建新订单时，任何包含该商品且此前未支付的订单都会流转至expired状态。只有最新订单可以付款。 | 如果用户尝试支付已过期的订单，支付UI将显示2002错误，付款将失败。 |
注：
如果用户正在完成付款时订单流转至expired状态，但付款成功，则订单会从expired流转至paid状态。仅当付款后不会超出订单中商品的购买限制时，此规则才适用。
免费商品
使用本部分中的调用向用户发放免费商品。
概述
购买限制可用于限制单个用户或所有用户可购买的商品数量。您还可以配置定期重置限制。
限制存储在艾克索拉侧，可在发布商帐户中按单个商品进行配置，也可在以下API调用中通过limits对象进行配置：
在以下用于获取商品目录的API调用中，限制信息会在items.limits对象中返回：
限制组的管理部分中的API调用可用于获取限制的当前状态，并针对特定用户更新限制，例如在任务完成后重置计数器，或手动调整剩余数量。
通用区域
区域销售限制用于控制商品可在哪些国家/地区或国家/地区组销售。例如，受授权许可限制时，您可以将某款游戏设置为仅在特定国家/地区销售。
销售限制通过区域进行配置。每个区域使用一个region_id标识符关联一个或多个国家/地区。您可以将一个商品关联到一个或多个区域。
商品是否可售按以下规则判断：
- 如果未为商品指定区域，则该商品可在所有国家/地区购买。
- 如果为商品指定了区域，且用户所在国家/地区包含在其中任一区域内，则该商品对该用户可售。
- 如果为商品指定了区域，但用户所在国家/地区不包含在任何指定区域内，则该商品对该用户不可售。
通过商品目录子部分中的API调用请求商品目录时，可通过country参数传入用户所在国家/地区。如果未传入该参数，系统会根据用户的IP地址判断其所在国家/地区。
系统会在两个环节校验用户所在国家/地区是否符合商品的区域设置：请求商品目录时和创建订单时。不可售商品不会返回在商品目录响应中；包含不可售商品的订单也无法创建。
如需创建、更新或删除区域，请使用通用区域组中的API调用。
区域销售限制设置流程：
- 使用创建区域API调用创建区域，并指定国家/地区列表。响应会返回下一步需要使用的
region_id。 - 创建或更新虚拟物品时，在
regions数组中传入该区域的region_id，将虚拟物品关联到该区域。 - 使用商品目录子部分中的API调用向用户展示商品目录，例如获取虚拟物品列表API调用。系统会根据
country参数确定用户所在国家/地区；如果未提供该参数，则根据用户的IP地址判断。用户所在国家/地区不可售的商品不会包含在商品目录响应中。 - 当用户继续支付商品或购物车时，创建订单：
- 如果商品已添加到购物车，请使用使用特定购物车中的所有商品创建订单或使用当前购物车中的所有商品创建订单API调用。
- 如需快速购买单个商品，请使用使用指定商品创建订单API调用，并传入商品SKU。
响应中包含用于打开支付UI的令牌。
艾克索拉会检查用户所在国家/地区是否包含在为商品指定的区域中。如果用户所在国家/地区不在该商品的区域范围内，则无法创建订单。
- 实现支付UI的打开逻辑，以便用户支付订单。
