Cas d'usage
Proposer un essai gratuit
Laissez les clients obtenir eux-mêmes une clé d'essai à durée limitée depuis votre propre site — Keyright la génère, l'envoie par e-mail, et votre application l'active exactement comme une clé payante — ou remettez à un évaluateur isolé (air-gapped) un fichier d'essai hors ligne signé.
Objectif
Laissez un prospect essayer votre produit avant de l’acheter, sans aucun travail de votre côté : il clique sur Start free trial sur votre site marketing, Keyright génère une licence d’essai à durée limitée, lui envoie la clé par e-mail, et votre application l’active exactement comme une clé payante. À l’expiration de l’essai, l’application retombe dans son état sans licence, et l’achat d’une vraie clé remplace l’essai sans réinstallation.
Tout au long de la page, $BASE est l’URL de votre service d’émission et $TOKEN est un jeton d’administration de tenant — voir Premiers pas.
Quand l’utiliser
- Utilisez ceci si vous voulez une évaluation en libre-service pilotée depuis votre propre site, un essai par e-mail et par produit, le compteur démarrant quand le client active.
- Utilisez ceci si vous avez un évaluateur isolé (air-gapped) ou en entreprise — remettez-lui plutôt un fichier d’essai hors ligne signé (ci-dessous), sans réseau nécessaire.
- N’utilisez pas ceci pour prolonger ou convertir un client payant — les renouvellements et les mises à niveau sont des modifications côté éditeur d’une licence existante (voir Activer, désactiver et déplacer des sièges). Les essais sont désactivés par défaut ; un produit n’en propose qu’une fois que vous avez défini une durée d’essai.
Ce que vous faites (côté éditeur)
1. Activer les essais sur un produit
Un essai est défini par trois éléments : les jours (durée ; <= 0 désactive), le niveau (le niveau de fonctionnalités accordé par l’essai) et les sièges.
Tableau de bord : ouvrez l’onglet Products et définissez la durée, le niveau et les sièges de l’essai sur le produit.
pro) et les sièges (1) — et confirme que n'importe qui peut en obtenir un en libre-service avec un e-mail professionnel.API — définissez-les sur un produit existant :
curl -X POST $BASE/admin/products/nebula/trial -H "X-Admin-Token: $TOKEN" -H "content-type: application/json" \
-d '{"days":30,"tier":"enterprise","seats":1}'
# -> { "product":"nebula", "trialDays":30, "trialTier":"enterprise", "trialSeats":1 }
Ou définissez-les à la création du produit (trialDays, trialTier, trialSeats sur POST /admin/products) :
curl -X POST $BASE/admin/products -H "X-Admin-Token: $TOKEN" -H "content-type: application/json" \
-d '{"name":"Nebula","slug":"nebula","trialDays":30,"trialTier":"enterprise","trialSeats":1}'
GET /admin/products renvoie les trialDays/trialTier/trialSeats de chaque produit. Mettez days à 0 pour désactiver à nouveau les essais.
2. Laisser un client demander un essai
POST /v1/trial est public (sans authentification) et ouvert au CORS, de sorte qu’un formulaire de navigateur sur votre site marketing peut lui envoyer une requête POST directement :
curl -X POST $BASE/v1/trial -H "content-type: application/json" \
-d '{"product":"nebula","email":"dev@acme.com","company":"Acme"}'
{
"ok": true,
"product": "nebula",
"trial": true,
"emailed": true,
"expiresUtc": "2026-10-23T12:00:00.0000000Z",
"days": 30,
"created": true
}
La réponse confirme que l’essai a été émis et envoyé par e-mail — elle ne contient délibérément pas la clé (aucun champ key, tier ni seats). Keyright envoie la clé d’essai par e-mail à l’adresse ; le client la saisit ensuite dans votre application, où elle s’active exactement comme une clé payante.
| Champ | Obligatoire | Notes |
|---|---|---|
product | oui | le slug du produit |
email | oui | l’essai est associé à cette adresse |
company | non | devient le nom du titulaire de la licence ; l’e-mail par défaut |
tenant | non | nécessaire uniquement si le même slug existe dans plus d’un tenant, pour lever l’ambiguïté |
Un essai par e-mail et par produit. Une nouvelle demande avec le même e-mail renvoie la même clé (created:false) au lieu d’en générer une nouvelle — idempotent et résistant aux abus, de sorte qu’un rafraîchissement ou un second clic ne remet jamais le compteur à zéro ni ne cumule les essais.
Réponses :
| Statut | Quand |
|---|---|
200 | essai émis (ou l’essai existant renvoyé) |
400 | email/product manquant ou invalide, ou le slug existe dans plus d’un tenant (passez tenant) |
403 | les essais ne sont pas activés pour ce produit (trialDays <= 0) |
404 | produit inconnu |
Brancher un bouton « Démarrer l’essai gratuit »
Comme /v1/trial est ouvert au CORS, une page statique peut l’appeler avec fetch :
<button id="trial">Start free trial</button>
<script>
document.getElementById('trial').onclick = async () => {
const res = await fetch('https://keyright.delta1labs.com/v1/trial', {
method: 'POST',
headers: { 'content-type': 'application/json' },
body: JSON.stringify({ product: 'nebula', email: userEmail, company: userCompany }),
});
const data = await res.json();
// La clé est envoyée par e-mail, pas renvoyée — invitez le client à consulter sa boîte de réception.
if (res.ok) show(`Check ${userEmail} for your trial key — it expires ${data.expiresUtc}.`);
else show(data.error);
};
</script>
Dans votre code
Le client reçoit la clé d’essai par e-mail, puis la saisit dans votre application — où elle s’active exactement comme une clé payante, sans chemin de code distinct pour l’essai. Vous la passez à activate() comme n’importe quelle clé payante. Avec Nebula, par exemple :
nebula register --key LIC-XXXXXXXXXXXXXXXXXXXX
Comme une clé d’essai s’active par exactement le même appel qu’une clé payante, il n’y a aucun chemin de code d’essai distinct à écrire — l’extrait d’activation pour .NET, Node.js, Python, Java et HTTP brut est le bloc multi-langages de Activer, désactiver et déplacer des sièges ; passez-lui la clé d’essai telle quelle. La forme CLI ci-dessus effectue une activation en ligne (POST /v1/activate), lie la machine et renvoie une lease signée avec trial:true et la date d’expiration de l’essai. Votre application le lit dans LicenseInfo : IsTrial == true, ExpiryUtc est la fin de l’essai et DaysRemaining décompte. Affichez la bannière d’évaluation (p. ex. « Essai Enterprise — 27 jours restants ») et verrouillez ce que vous voulez derrière info.IsTrial. Grâce à la lease mise en cache, l’application continue de fonctionner hors ligne jusqu’à l’expiration de l’essai ; à l’expiration, la lease cesse d’être validée et l’application échoue en mode fermé vers l’état gratuit/sans licence (voir Intégration du SDK .NET).
Les essais tiennent compte de la durée depuis la première activation et de la manipulation de l’horloge — un client ne peut pas regagner du temps en reculant l’horloge. Le passage de l’essai au payant est transparent : quand le client achète et active une clé hors essai, celle-ci remplace l’essai restant sans réinstallation. La forme complète de l’activation pour les clés d’essai, à durée et perpétuelles se trouve dans Activer, désactiver et déplacer des sièges.
Essais hors ligne pour les évaluateurs isolés (air-gapped)
Les essais en libre-service empruntent le chemin en ligne, mais ce n’est pas la seule façon d’essayer. Pour un évaluateur isolé (air-gapped) ou en entreprise, vous pouvez aussi remettre un fichier de licence d’essai hors ligne, signé et à durée limitée — sans aucun réseau. Avec la CLI de Nebula :
nebula license --sign --trial --tier enterprise --expiry 2026-10-23 \
--licensee "Acme Corp" --private-key ./keys/nebula.private.json --out acme-trial.json
Le fichier porte l’indicateur trial et un expiryUtc ; le SDK le valide avec la clé publique embarquée et le traite comme un essai jusqu’à son expiration. C’est l’équivalent hors ligne du flux en libre-service ci-dessus — même sémantique d’essai, livrée sous forme de fichier plutôt que d’activation. Voir Fonctionner hors ligne / isolé (air-gapped).
Cloud ou auto-hébergé
Seules deux choses changent entre Keyright Cloud et l’auto-hébergement : l’URL $BASE (Cloud est https://keyright.delta1labs.com) et l’origine de $TOKEN. Un point est réellement propre au mode :
- Les essais en libre-service ont besoin de SMTP. Keyright remet la clé d’essai par e-mail, l’instance doit donc avoir SMTP configuré (
KEYRIGHT_SMTP_*) — sans cela, l’essai est généré mais le client ne reçoit jamais la clé. Sur Keyright Cloud, l’envoi d’e-mails est déjà câblé ; en auto-hébergé, vous le configurez vous-même. - Le chemin du fichier d’essai hors ligne n’a besoin ni de SMTP (ni de réseau).
Vérifier
- Activez les essais sur le produit (
days > 0), puis envoyezPOST /v1/trialavec un e-mail de test — attendez-vous à un200avec"emailed": trueet unexpiresUtc. - Consultez la boîte de réception pour la clé d’essai, et confirmez que la vue Licenses du tableau de bord affiche désormais une licence d’essai pour cet e-mail.
- Activez la clé dans votre application et confirmez qu’elle affiche la bannière d’évaluation avec
IsTrial == trueet unDaysRemainingqui décompte. - Redemandez l’essai avec le même e-mail — attendez-vous à recevoir la même clé et
"created": false(pas de nouvelle licence, pas de remise à zéro du compteur).
Voir aussi
- Premiers pas — émettez et vérifiez votre première licence (payante).
- Activer, désactiver et déplacer des sièges — comment les clés d’essai, à durée et perpétuelles s’activent et apparaissent dans
LicenseInfo. - Fonctionner hors ligne / isolé (air-gapped) — fichiers de licence et d’essai hors ligne signés.
- Référence de l’API HTTP — la carte complète des endpoints, y compris
/v1/trial.