Passer au contenu

LiveOps API (2.0.0)

Aperçu

  • Version : 2.0.0
  • Serveurs : https://store.xsolla.com/api
  • Contactez-nous par e-mail
  • URL de contact : https://xsolla.com/
  • Version TLS requise : 1.2

LiveOps est un ensemble d'outils permettant de stimuler l'engagement continu des joueurs grâce à des promotions et des offres personnalisées.

Utilisez l'API pour gérer les fonctionnalités suivantes :

  • Promotions — créez et gérez des campagnes par coupons, codes promo, réductions et bonus.
  • Personnalisation — spécifiez les conditions d'affichage du catalogue des objets et appliquez des promotions uniquement pour certains utilisateurs autorisés.
  • Limites de promotion — définissez une limite sur le nombre d'utilisations d'une promotion par utilisateur et configurez des réinitialisations planifiées de ces limites.
  • Chaînes de récompenses et points de valeur — configurez des parcours de récompenses débloqués progressivement selon l'accumulation de points de valeur.
  • Chaînes quotidiennes — configurez des récompenses quotidiennes récurrentes pour encourager les connexions régulières.
  • Chaînes d'offres — créez des offres d'achat séquentielles avec une tarification par paliers et des options de récompense gratuite.
  • Upsell — méthode de vente consistant à proposer à l'utilisateur l'achat d'un objet à valeur ajoutée.

Appels API

L'API est divisée en groupes suivants :

  • Admin — appels pour créer, mettre à jour, activer et supprimer des campagnes et des configurations de chaînes. Authentifié via authentification d'accès de base avec vos identifiants de commerçant ou de projet.
  • Client — appels pour récupérer les promotions disponibles, obtenir des chaînes actives, utiliser des codes et réclamer des récompenses au nom des utilisateurs finaux authentifiés. Authentifié via JWT utilisateur.

Authentification

Les appels API nécessitent une authentification au nom d'un utilisateur ou d'un projet. Le schéma d'authentification à utiliser figure dans la section Security de la description de chaque appel.

Authentification à l'aide du JWT utilisateur

L'authentification par JWT utilisateur est utilisée lorsqu'une requête provient d'un navigateur, d'une application mobile ou d'un jeu. Par défaut, le schéma XsollaLoginUserJWT s'applique. Pour savoir comment créer un jeton, consultez la documentation de l'API Xsolla Login.

Transmettez le jeton dans l'en-tête Authorization au format suivant : Authorization: Bearer <user_JWT>, où <user_JWT> représente le jeton utilisateur. Ce jeton identifie l'utilisateur et donne accès à ses données personnalisées.

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

Authentification HTTP basique

L'authentification HTTP basique est utilisée pour les interactions serveur à serveur, lorsqu'un appel API est envoyé directement depuis votre serveur plutôt que depuis le navigateur ou l'application mobile d'un utilisateur. Elle repose généralement sur une clé API.

Note

La clé API est confidentielle et ne doit jamais être stockée ni utilisée dans une application cliente.

Avec l'authentification basique côté serveur, toutes les requêtes API doivent inclure l'en-tête suivant :

  • pour basicAuth — Authorization: Basic <your_authorization_basic_key>, où your_authorization_basic_key est la paire project_id:api_key encodée en Base64
  • pour basicMerchantAuth — Authorization: Basic <your_authorization_basic_key>, où your_authorization_basic_key est la paire merchant_id:api_key encodée en Base64

Vous trouverez les valeurs des paramètres dans le Compte éditeur :

  • merchant_id s'affiche :
    • Dans Company settings > Company*.
    • Dans l'URL dans la barre d'adresse du navigateur sur n'importe quelle page du Compte éditeur. L'URL a le format suivant : https://publisher.xsolla.com/<merchant_id>.
  • project_id s'affiche :
    • À côté du nom du projet dans le Compte éditeur.
    • Dans l'URL dans la barre d'adresse du navigateur lors de l'utilisation d'un projet dans le Compte éditeur. L'URL a le format suivant : https://publisher.xsolla.com/<merchant_id>/projects/<project_id>.
  • api_key s'affiche dans le Compte éditeur uniquement au moment de la création et doit être stockée en toute sécurité de votre côté. Vous pouvez créer une clé API dans les sections suivantes :
Remarque

Si un appel API requis n'inclut pas le paramètre de chemin project_id, utilisez une clé API valide pour l'ensemble des projets de l'entreprise pour l'autorisation.

Pour plus d'informations sur l'utilisation des clés API, consultez les références API.

Authentification avec prise en charge de l'accès invité

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

  1. Authentification par JWT utilisateur. Le jeton est passé dans l'en-tête Authorization au format suivant : Authorization: Bearer <user_JWT>, où <user_JWT> est le jeton utilisateur. Le jeton identifie l'utilisateur et donne accès aux données personnalisées. Vous pouvez également utiliser un jeton pour ouvrir l'interface de paiement.

  2. Mode simplifié sans en-tête Authorization. Ce mode est réservé aux utilisateurs non authentifiés et peut être utilisé uniquement pour la vente de clés de jeu. Au lieu d'un jeton, la requête doit inclure les en-têtes suivants :

    • x-unauthorized-id avec un identifiant de requête
    • x-user avec l'adresse e-mail de l'utilisateur encodée en Base64

Structure de l'entité principale

Les objets de tous types (objets virtuels, lots, monnaie virtuelle et clés) partagent une structure de données similaire. Comprendre cette structure de base facilite l’utilisation de l'API et la navigation dans la documentation.

Note

Certains appels peuvent inclure des champs supplémentaires, mais ils ne modifient pas la structure de base.

Identification

  • merchant_id — ID de l'entreprise dans le Compte éditeur
  • project_id — ID de projet dans le Compte éditeur
  • sku — UGS de l'objet, unique au sein du projet

Affichage en magasin

  • name — nom de l'objet
  • description — description de l'objet
  • image_url — URL de l'image
  • is_enabled — disponibilité de l'objet
  • is_show_in_store — affichage de l'objet dans le catalogue

Pour plus d'informations sur la gestion de la disponibilité des objets dans le catalogue, consultez la documentation.

Organisation

  • type — type d'objet, par exemple, un objet virtuel (virtual_item) ou un lot (bundle)
  • groups — groupes auxquels l'objet appartient
  • order — ordre d'affichage dans le catalogue

Conditions de vente

  • prices — prix en devise réelle ou monnaie virtuelle
  • limits — limites d'achat
  • periods — périodes de disponibilité
  • regions — restrictions régionales

Exemple de structure d'entité principale :

{
  "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": []
}

Processus d'achat de base

L'API Xsolla vous permet d'implémenter la logique de magasin en jeu, notamment la récupération du catalogue des objets, la gestion du panier, la création de commandes et le suivi de leur statut. Selon le scénario d'intégration, les appels API sont répartis en sections Administrateur et Catalogue, qui utilisent différents schémas d'authentification.

L'exemple suivant montre un processus de base pour configurer et exploiter un magasin, de la création d'objets à l'achat.

Création d'objets et de groupes (Administrateur)

Créez un catalogue des objets pour votre magasin, tels que des objets virtuels, des lots ou de la monnaie virtuelle.

Exemples d'appels API :

Configuration de promotions, chaînes et limites (Administrateur)

Configurez des outils d'acquisition d'utilisateurs et de monétisation, tels que des remises, des bonus, des récompenses quotidiennes ou des chaînes d'offres.

Exemples d'appels API :

Récupération d'informations sur un objet (Client)

Configurez l'affichage des objets dans l'application.

Remarque

N'utilisez pas les appels API de la sous-section Administrateur pour créer un catalogue utilisateur. Ces appels API présentent des limites de taux et ne sont pas destinés au trafic utilisateur.

Exemples d'appels API :

Note

Par défaut, les appels API du catalogue renvoient les objets disponibles dans la boutique au moment de la requête. Pour récupérer les objets inactifs ou à durée limitée, ajoutez le paramètre "show_inactive_time_limited_items": 1 dans la requête du catalogue.

Vente des objets

Vous pouvez vendre des objets en utilisant les méthodes suivantes :

  • Achat rapide — vendre une UGS plusieurs fois.
  • Achat via le panier — l'utilisateur ajoute des objets au panier, supprime des objets et modifie les quantités dans une seule commande.

Si un objet est acheté en utilisant de la monnaie virtuelle au lieu des devises réelles, 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, car le coût est traité lors de l'exécution de l'appel API.

Pour l'achat d'un objet gratuit, utilisez l'appel API Créer une commande avec un bien gratuit spécifique ou l'appel API Créer une commande à partir d'un panier gratuit. L'interface de paiement n'est pas requise, la commande est immédiatement définie sur le statut done.

Achat rapide

Utilisez l'appel API côté client pour créer une commande à partir d'un objet spécifique. L'appel renvoie un jeton utilisé pour ouvrir l'interface de paiement.

Note

Les informations sur les remises sont disponibles pour l'utilisateur uniquement dans l'interface de paiement. Les codes promo ne sont pas pris en charge.

Achat via le panier

La configuration et les achats du panier peuvent être gérés côté client ou côté serveur.

Configuration et achat du panier côté client

Implémentez vous-même la logique d'ajout et de suppression des objets. Avant d'appeler l'API pour configurer un panier, vous ne disposerez pas d'informations sur les promotions qui s'appliqueront à l'achat. Le coût total ainsi que les informations des objets bonus ajoutés ne seront donc pas encore connus.

Implémentez la logique suivante pour le panier :

  1. Après que le joueur a rempli un panier, utilisez l'appel API Remplir le panier d'objets. L'appel renvoie les informations actuelles sur les objets sélectionnés (prix avant et après remises, objets bonus).
  2. Mettez à jour le contenu du panier en fonction des actions utilisateur :
Note

Pour obtenir le statut actuel du panier, utilisez l'appel API Lire le panier de l'utilisateur actuel.
  1. Utilisez l'appel API Créer une commande à partir de tous les objets du panier actuel. L'appel renvoie l'ID de commande et le jeton de paiement. La commande nouvellement créée est définie sur le statut new par défaut.

Configuration et achat du panier côté serveur

Cette approche peut nécessiter davantage de temps pour configurer le panier, car chaque modification doit être effectuée via des appels API.

Implémentez la logique suivante pour le panier :

  1. Après que le joueur a rempli un panier, utilisez l'appel API Remplir le panier d'objets. L'appel renvoie les informations à jour sur les objets sélectionnés (prix avant et après remises, objets bonus).
  2. Utilisez l'appel API Créer une commande à partir de tous les objets du panier actuel. L'appel renvoie l'ID de commande et le jeton de paiement. La commande nouvellement créée est définie sur le statut new par défaut.

Ouverture de l'interface de paiement

Utilisez le jeton renvoyé pour ouvrir l'interface de paiement dans une nouvelle fenêtre. D'autres méthodes d'ouverture de l'interface de paiement sont décrites dans la documentation.

ActionEndpoint
Ouverture dans l'environnement de production.https://secure.xsolla.com/paystation4/?token={token}
Ouverture en mode bac à sable.https://sandbox-secure.xsolla.com/paystation4/?token={token}
Note

Utilisez le mode bac à sable pendant le développement et les tests. Les achats de test n'entraînent aucun débit sur des comptes réels. Vous pouvez utiliser des cartes bancaires de test.

Après le premier paiement réel, une politique stricte du mode bac à sable s'applique. Les paiements en mode bac à sable sont disponibles uniquement pour les utilisateurs spécifiés dans la section Company settings > Users du Compte éditeur.

L'achat de monnaie virtuelle et d'objets en devise réelle n'est possible qu'après la signature d'un contrat de licence avec Xsolla. Pour cela, dans le Compte éditeur, accédez à Agreements & Taxes > Agreements, complétez le formulaire et attendez la validation. Le traitement du contrat peut prendre jusqu'à 3 jours ouvrés.

Pour activer ou désactiver le mode bac à sable, modifiez la valeur du paramètre sandbox dans la requête pour l'achat rapide et l'achat via le panier. Le mode bac à sable est désactivé par défaut.

Statuts de commande possibles :

  • new — commande créée
  • paid — paiement reçu
  • done — objet attribué
  • canceled — commande annulée
  • expired — commande expirée

Suivez le statut de la commande en utilisant l'une des méthodes suivantes :

Pagination

Les appels API qui renvoient de grands ensembles d'enregistrements (par exemple lors de la création d'un catalogue) utilisent la pagination. La pagination est un mécanisme qui limite le nombre d'objets renvoyés dans une seule réponse et permet de récupérer les pages suivantes de manière séquentielle.

Utilisez les paramètres suivants pour contrôler le nombre d'objets renvoyés :

  • limit — nombre d'objets par page
  • offset — indice du premier objet sur la page (la numérotation commence à 0)
  • has_more — indique si une autre page est disponible
  • total_items_count — nombre total d'objets

Exemple de requête :

GET /items?limit=20&offset=40

Exemple de réponse :

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

Il est recommandé d'envoyer des requêtes successives jusqu'à ce que la réponse renvoie has_more = false.

Format de date et d'heure

Les dates et les valeurs temporelles sont transmises au format ISO 8601.

Les valeurs suivantes sont prises en charge :

  • Décalage UTC
  • Valeur null lorsqu'il n'y a pas de restriction temporelle pour l'affichage d'un objet
  • Horodatage Unix (en secondes) utilisé dans certains champs

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

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

Localisation

Xsolla prend en charge la localisation des champs destinés aux utilisateurs, tels que le nom et la description de l'objet. Les valeurs localisées sont transmises sous forme d'objet, où le code de langue est utilisé comme clé. La liste complète des langues prises en charge est disponible dans la documentation.

Champs pris en charge

Les paramètres suivants peuvent être localisés :

  • name
  • description
  • long_description

Format de langue

La clé de la langue peut être spécifiée dans l'un des formats suivants :

  • Code de langue à deux lettres : en, ru
  • Code de langue à cinq lettres : en-US, ru-RU, de-DE

Exemples

Exemple avec un code de langue à deux lettres :

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

Exemple avec un code de langue à cinq lettres :

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

Format de réponse d'erreur

En cas d'erreur, l'API renvoie un statut HTTP ainsi qu'un corps de réponse au format JSON. La liste complète des erreurs liées au magasin est disponible dans la documentation.

Exemple de réponse :

{
  "errorCode": 1102,
  "errorMessage": "Validation error",
  "statusCode": 422,
  "transactionId": "c9e1a..."
}
  • errorCode — code d'erreur.
  • errorMessage — courte description de l'erreur.
  • statusCode — statut de la réponse HTTP.
  • transactionId — ID de la requête. Retourné uniquement dans certains cas.
  • errorMessageExtended — informations supplémentaires sur l'erreur, telles que les paramètres de la requête. Retournées uniquement dans certains cas.

Exemple de réponse détaillée :

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

Codes de statut HTTP courants

  • 400 — requête non valide
  • 401 — erreur d'authentification
  • 403 — permissions insuffisantes
  • 404 — ressource non trouvée
  • 422 — erreur de validation
  • 429 — limite de taux dépassée

Recommandations

  • Gérez ensemble le statut HTTP et le corps de la réponse.
  • Utilisez errorCode pour traiter les erreurs liées à la logique de l'application.
  • Utilisez transactionId pour identifier plus rapidement les requêtes lors de l'analyse des erreurs.
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/liveops/

Aperçu

Les promotions sont des outils marketing conçus pour attirer de nouveaux utilisateurs et augmenter les ventes. Avec l'API Xsolla, vous pouvez configurer les promotions suivantes :

  • Réductions — prix réduits sur des objets sélectionnés.
  • Bonus — objets accordés aux utilisateurs lors d'un achat.
  • Coupons — codes permettant aux utilisateurs d'obtenir un ou plusieurs objets bonus lors de leur utilisation.
  • Codes promo — codes permettant aux utilisateurs d'obtenir des objets bonus, une remise sur un objet spécifique ou une remise sur l'ensemble du panier. Contrairement aux coupons, qui sont utilisés après avoir été saisis par l'utilisateur, les codes promo s'appliquent lors de l'achat, au moment du paiement.
  • Offres uniques — objets cachés affichés dans le catalogue uniquement aux utilisateurs ayant saisi un code d'offre unique. Sans ce code, les objets ne sont pas affichés.

Exemple de flux de configuration d'une promotion par réduction :

  1. Créez des objets en utilisant les appels de la sous-section Administrateur des groupes Objets et devises virtuels, Lots, ou Clés de jeu.
  2. Créez une promotion en utilisant l'appel Créer une promotion par réduction pour un objet. Dans le tableau items, passez les UGS des objets nécessaires.
  3. Configurez les périodes de validité de la promotion. Pour ce faire, appelez les méthodes Créer une promotion par réduction pour un objet ou Mettre à jour la promotion pour un objet, et passez le champ promotion_periods comme un tableau d'objets où date_from définit la date de début et date_until définit la date de fin de la période de validité.
  4. Activez la promotion en utilisant l'appel Mettre à jour la promotion sur les objets. Passez le paramètre "is_enabled": true.
  5. Pour obtenir des informations sur les prix des objets, y compris les prix réduits, appelez les méthodes API client de récupération du catalogue des objets à partir des sous-sections Common > Catalog, Virtual Items and Currency > Catalog, et Bundles > Catalog.

Exemple de configuration de promotion

Consultez notre documentation pour obtenir des informations détaillées sur la configuration des promotions :

Appels API communs

Appelez les méthodes API de cette sous-section pour gérer différents types de promotions.

Opérations

Coupons

Appelez les méthodes API de cette sous-section pour configurer et gérer les promotions par coupon.

Note

Consultez notre documentation pour obtenir des informations détaillées sur les coupons.

Opérations

Codes promo

Appelez les méthodes API de cette sous-section pour configurer et gérer les promotions par code promo.

Note

Consultez notre documentation pour obtenir des informations détaillées sur les codes promo.

Opérations

Offres uniques du catalogue

Appelez les méthodes API de cette sous-section pour configurer et gérer les offres de catalogue uniques.

Note

Consultez notre documentation pour des informations détaillées sur les offres uniques.

Opérations

Remises

Appelez les méthodes API de cette sous-section pour configurer et gérer les promotions par réduction.

Note

Consultez notre documentation pour obtenir des informations détaillées sur les remises.

Opérations

Bonus

Appelez les méthodes API de cette sous-section pour configurer et gérer les promotions par bonus.

Note

Consultez notre documentation pour obtenir des informations détaillées sur les bonus.

Opérations

Catalogue personnalisé

La personnalisation permet de définir des conditions d’affichage du catalogue d’objets et d’appliquer des promotions uniquement à certains utilisateurs autorisés. Ces conditions, basées sur les attributs utilisateur, permettent de proposer des objets et des promotions adaptés à des profils spécifiques.

Les types de personnalisation suivants sont disponibles :

  • Personnalisation côté Xsolla — les règles et la logique de personnalisation sont configurées et stockées côté Xsolla. Vous transmettez les attributs utilisateur, puis Xsolla les utilise pour générer un catalogue personnalisé.
  • Personnalisation côté partenaire — vous configurez les règles et la logique de personnalisation de votre côté, puis envoyez à Xsolla la charge utile du catalogue final pour un utilisateur spécifique.
Note

Vous ne pouvez utiliser qu'un seul type de personnalisation. Pour le changer, suivez les instructions.

Pour configurer la personnalisation côté Xsolla en utilisant l'API Xsolla :

  1. Créez des objets via les appels API de la sous-section Administrateur des groupes Objets et monnaie virtuels, Lots ou Clés de jeu.

  2. Configurez les attributs utilisateur en utilisant Xsolla Login API et maintenez-les synchronisés en mettant à jour les données dans Xsolla à chaque changement dans votre jeu.

  3. Configurez la personnalisation pour les objets ou les promotions :

    • Pour personnaliser le catalogue des objets, définissez les règles d'affichage du catalogue via l'appel API Créer une règle de filtrage du catalogue :
      • Dans le tableau attribute_conditions, spécifiez les conditions qui déterminent la disponibilité des objets en fonction des attributs utilisateur.
      • Dans le tableau items, fournissez la liste des objets qui sont visibles pour l'utilisateur si ses attributs correspondent aux conditions spécifiées.
    • Pour configurer des promotions personnalisées, utilisez les appels API de création et de mise à jour pour le type de promotion requis. Dans le tableau attribute_conditions, spécifiez les conditions qui déterminent la disponibilité de la promotion en fonction des attributs utilisateur.

  4. Passez le JWT utilisateur avec les attributs utilisateur aux appels API de récupération du catalogue pour recevoir un catalogue personnalisé.

Séquence pour configurer et appliquer la personnalisation côté Xsolla pour le catalogue des objets :

Personnalisation pour le catalogue des objets

Séquence pour configurer et appliquer la personnalisation côté Xsolla pour les promotions :

Personnalisation pour les promotions

Note

Des informations détaillées sont fournies :
Opérations

Aperçu

Les limites d'utilisation des promotions permettent de restreindre le nombre de fois qu'un utilisateur peut utiliser une promotion. Vous pouvez également configurer des réinitialisations de limites planifiées.

Les limites sont stockées côté de Xsolla et configurées dans les paramètres de promotion 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.promotions.limits dans les appels API suivants de récupération du 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 Promotion usage limits.

Vous pouvez configurer limits.per_user — une limite du nombre d'utilisations d'une promotion par utilisateur unique.

Les utilisateurs non authentifiés voient toujours le nombre maximal d'utilisations de la promotion.

Pour afficher le nombre d'utilisations restantes d'une promotion pour un utilisateur, avec la limite active appliquée, passez les données d'autorisation de l'utilisateur lors de la requête du catalogue des objets.

Pour configurer une période de réinitialisation planifiée, quotidienne, hebdomadaire ou mensuelle — passez l'objet limits.recurrent_schedule lors de la création ou de la mise à jour d'une promotion.

Scénario de configuration et d'application des limites

  1. Vous créez une promotion en utilisant l'appel API Créer une promotion par réduction pour un objet ou l'appel API Créer une promotion par bonus et vous passez l'objet limits.
  2. Vous interrogez le catalogue pour un utilisateur non authentifié, la réponse renvoie le nombre maximum d'utilisations de la promotion dans l'objet items.promotions.limits.
  3. L'utilisateur se connecte.
  4. Vous demandez le catalogue avec le jeton d'autorisation de l'utilisateur, la réponse renvoie le nombre d'utilisations restantes avec la limite active appliquée.
  5. L'utilisateur sélectionne un objet promotionnel et effectue un achat.
  6. Après un paiement réussi, Xsolla met à jour la valeur items.promotions.limits.per_user. Lorsqu'elle atteint 0, l'objet est retourné dans les appels API du catalogue sans remise ni bonus.
  7. Vous pouvez mettre à jour la limite en utilisant les appels API de la sous-section Management :
  8. Vous récupérez la valeur de limite mise à jour dans items.promotions.limits lors de la prochaine requête du catalogue effectuée avec le jeton d'autorisation de l'utilisateur, puis vous l'affichez à l'utilisateur.

Limites de promotion

Gestion

Opérations

Aperçu

Les chaînes de récompense incitent les utilisateurs à effectuer des achats en magasin avec des devises réelles. Chaque achat génère des points de valeur et fait progresser la chaîne de récompenses. Dans les clans, les achats contribuent également aux points de valeur de l'ensemble du clan. Pour plus d'informations sur la configuration des chaînes de récompenses, consultez la section Système de récompenses.

Configurez les chaînes de récompense via les appels API de la section Administrateur. Pour les afficher et récupérer les récompenses, utilisez les appels API de la section Client. Gérez les chaînes de clans via les appels API de la section Client clans.

Exemple de flux de configuration d'une chaîne de récompenses :

  1. Créez des objets via les appels API de la sous-section Administrateur des groupes Objets et monnaie virtuels ou Lots.
  2. Créez des points de valeur via l'appel API Créer un point de valeur.
  3. Attribuez des points de valeur aux objets en utilisant l'appel API Définir des points de valeur pour des objets. Les utilisateurs reçoivent des points de valeur à l'achat de ces objets.
  4. Créez une chaîne à l'aide de l'appel API Créer une chaîne de récompenses. Pour activer la chaîne, passez le paramètre is_enabled: true.
  5. Implémentez l'affichage de la chaîne de récompenses. Pour ce faire, demandez la liste des chaînes disponibles à l'aide de l'appel API Lire les chaînes de récompenses actuelles d'un utilisateur. La réponse contient toutes les chaînes actives, avec leurs étapes et leurs statuts.
  6. Implémentez l'affichage du solde de points de valeur. Pour ce faire, utilisez l'appel API Lire le solde de points de valeur de l'utilisateur actuel.
  7. Implémentez le système de réclamation des récompenses par étape. Pour ce faire, utilisez l'appel API Réclamer la récompense d'une étape .
  8. Configurez le suivi du statut des commandes, par exemple via des webhooks, afin de recevoir rapidement les données des récompenses réclamées et de les attribuer aux utilisateurs.

Flux de configuration de la chaîne de récompenses

Administrateur

Opérations

Client

Opérations

Client clans

Opérations

Administrateur

Opérations

Client

Opérations

Aperçu

Les chaînes d'offres sont une suite d'étapes contenant chacune un objet, que les utilisateurs peuvent recevoir gratuitement ou acheter dans le cadre d'une offre active. Elles peuvent inclure des objets exclusifs disponibles uniquement dans la chaine, ainsi que des objets à prix réduit par rapport au magasin. Pour plus d'informations sur la configuration de cet outil marketing, consultez la section Chaînes d'offres.

Pour configurer les chaînes d'offres, utilisez les appels API de la sous-section Administrateur. Pour afficher les chaînes et implémenter la logique de gestion des objets reçus par les utilisateurs, utilisez les appels API de la sous-section Client.

Exemple de flux de configuration d'une chaîne de d'offres :

  1. Créez des objets en utilisant les appels API de la sous-section Administrateur des groupes Objets et monnaie virtuels ou Lots.

  2. Créez une chaîne en utilisant l'appel API Créer une chaîne d'offres. Pour activer la chaîne, passez le paramètre is_enabled: true.

  3. Implémentez l'affichage des chaînes d'offres. Pour ce faire, récupérez la liste des chaînes disponibles en utilisant l'appel API Lire les chaînes d'offres de l'utilisateur actuel. La réponse contient toutes les chaînes actives avec leurs étapes et leurs statuts.

  4. Implémentez la logique pour traiter les objets que les utilisateurs reçoivent :

  5. Configurez le suivi du statut des commandes, par exemple en utilisant des webhooks, afin de recevoir rapidement les informations sur les objets réclamés ou achetés et de les attribuer à l'utilisateur.

Flux de configuration de la chaîne de récompenses

Administrateur

Opérations

Client

Opérations

Administrateur

Opérations

Client

Opérations