API de gestion de licences pour softwares
Cette API ajoute des codes licences à n'importe quel logiciel (application desktop, plugin, add-on, service web, jeu…).
Elle permet à des éditeurs de créer des licences, les activer sur un appareil, les désactiver et les administrer simplement — chacun pour son propre produit, isolé de tous les autres éditeurs de la plateforme.
Technologie & auteur
- Développée en Python avec FastAPI et PostgreSQL.
- Conçue et maintenue par XP-Flightdeck.
Trois acteurs, pas deux
- La plateforme (nous) — provisionne les comptes éditeur, chacun avec son propre
X-Client-Token/X-Admin-Token, générés une fois et jamais stockés en clair. - Un éditeur (studio de jeu, SaaS, éditeur de logiciel) — intègre l'API dans son propre produit, gère ses propres licences via
/admin/*. Le token admin d'un éditeur ne peut jamais voir les données d'un autre éditeur. - L'utilisateur final — le client de l'éditeur. Il ne parle jamais directement à cette API : il reçoit une clé de licence de l'éditeur et la saisit dans le logiciel de l'éditeur, qui appelle
/activateen son nom.
Cibles, par ordre de priorité : 1. Éditeurs de jeux (jeux, plugins, DLC, mods, assets) 2. Éditeurs SaaS (applications web et services cloud) 3. Éditeurs de logiciels (Desktop & On-Premise)
À quoi ça sert ?
- Protéger vos fonctionnalités “pro” : seul un utilisateur final avec une licence valide y accède.
- Limiter par appareil : un éditeur décide du nombre de machines autorisées par licence d'un de ses utilisateurs.
- Suspendre / reprendre : mettez une licence en pause puis réactivez-la.
- Voir l'usage : liste des licences, appareils actifs, dates clés — scopé à votre propre compte éditeur.
- Sécurité : les réponses d'activation sont signées (Ed25519, avec rotation possible) pour éviter la falsification ;
/activateest limité en débit par utilisateur final, pas seulement par éditeur.
Fonctionnalités - en bref
0) Provisionnement d'un éditeur (Platform)
L'opérateur de la plateforme crée un compte éditeur, qui reçoit un client_token et un admin_token une seule fois. Tout ce qui suit est scopé à cet éditeur.
1) Création de licences (Admin)
Générez des clés uniques avec des attributs (produit/édition, quota d'activations par utilisateur final, features).
Idéal pour l'onboarding, les bundles, les essais et les remplacements.
2) Activation côté application
Au premier lancement, l'app de l'éditeur envoie l'email, la clé de licence de son utilisateur final et un identifiant d'appareil.
L'API valide et renvoie un jeton signé que l'app peut conserver comme preuve.
3) Désactivation d'un appareil
Quand l'utilisateur final change de machine, on libère un slot pour réutiliser la licence ailleurs.
Déclenchable côté app ou par un admin.
4) Gestion & reporting (Admin)
Recherchez et listez les licences (email, produit, édition, statut), paginé.
Consultez les appareils actifs et l'historique d'activation pour le support — plus un journal d'audit append-only de toute action admin.
5) Activer / désactiver une licence (Admin)
Suspendez temporairement (remboursement, abus) ou réactivez la licence.
Effet immédiat, sans toucher aux appareils.
6) Health-check & vérification de clé
Un endpoint health confirme que l'API répond. GET /public-keys expose toutes les clés de signature (active + retirées) pour que les jetons restent vérifiables après une rotation.
Scénarios couverts
- Logiciel desktop / plugin avec options “Pro”.
- Abonnements avec nombre d'appareils limité (ex. 2 machines).
- Essais (limités dans le temps + quota d'activations).
Intégration (vision non-technique)
- Être provisionné comme éditeur (l'opérateur de la plateforme crée votre compte).
- Créer une licence pour votre utilisateur final (outil admin ou script).
- Activer au premier lancement de votre app.
- Conserver le jeton signé côté app.
- Désactiver l'ancien appareil si votre utilisateur final migre.
Les détails techniques (exemples, formats) sont dans les pages Guides et Référence.