Skip to content

Anwendungsfälle

Eine kostenlose Testversion anbieten

Lassen Sie Kunden sich einen zeitlich begrenzten Testschlüssel per Self-Service von Ihrer eigenen Website holen — Keyright stellt ihn aus, sendet ihn per E-Mail, und Ihre App aktiviert ihn genau wie einen bezahlten Schlüssel — oder geben Sie einem netzwerkisolierten (air-gapped) Evaluator eine signierte Offline-Testdatei.

Ziel

Lassen Sie einen Interessenten Ihr Produkt vor dem Kauf ausprobieren, ohne Aufwand auf Ihrer Seite: Er klickt auf Ihrer Marketing-Website auf Kostenlose Testversion starten, Keyright stellt eine zeitlich begrenzte Testlizenz aus, sendet ihm den Schlüssel per E-Mail, und Ihre App aktiviert ihn genau wie einen bezahlten Schlüssel. Läuft die Testversion ab, fällt die App in ihren unlizenzierten Zustand zurück, und der Kauf eines echten Schlüssels ersetzt die Testversion ohne Neuinstallation.

Durchgängig steht $BASE für die URL Ihres Issuing-Service und $TOKEN für ein Mandanten-Admin-Token — siehe Erste Schritte.

Wann Sie es einsetzen

  • Verwenden Sie dies, wenn Sie eine Self-Service-Evaluierung von Ihrer eigenen Website aus möchten, eine Testversion pro E-Mail-Adresse und Produkt, wobei die Uhr mit der Aktivierung durch den Kunden zu laufen beginnt.
  • Verwenden Sie dies, wenn Sie einen netzwerkisolierten (air-gapped) oder Enterprise-Evaluator haben — geben Sie ihm stattdessen eine signierte Offline-Testdatei (siehe unten), ganz ohne Netzwerk.
  • Verwenden Sie dies nicht, um einen zahlenden Kunden zu verlängern oder umzustellen — Verlängerungen und Upgrades sind anbieterseitige Änderungen an einer bestehenden Lizenz (siehe Aktivieren, deaktivieren & Plätze verschieben). Testversionen sind standardmäßig deaktiviert; ein Produkt bietet sie erst an, wenn Sie eine Testdauer festlegen.

Was Sie tun (Anbieterseite)

1. Testversionen für ein Produkt aktivieren

Eine Testversion wird durch drei Dinge definiert: Tage (Dauer; <= 0 deaktiviert), Tier (das Funktions-Tier, das die Testversion gewährt) und Plätze.

Dashboard: Öffnen Sie den Tab Products und legen Sie Testdauer, Tier und Plätze am Produkt fest.

Die Produktseite „Acme App“ in Keyright mit einer Trial-Karte „14-day trial · pro“ und dem Hinweis „14 days on the pro edition with 1 seat(s). Anyone can request one with their work email.“, neben den Editionen des Produkts (enterprise, pro, starter) und seinem produktspezifischen Signaturschlüssel.
Die Trial-Karte des Produkts legt die drei Bestandteile einer Testversion fest — Dauer (14 Tage), Tier (pro) und Plätze (1) — und bestätigt, dass sich jeder mit einer geschäftlichen E-Mail-Adresse selbst eine holen kann.

API — legen Sie sie für ein bestehendes Produkt fest:

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 }

Oder legen Sie sie beim Anlegen des Produkts fest (trialDays, trialTier, trialSeats bei 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 liefert für jedes Produkt trialDays/trialTier/trialSeats. Setzen Sie days auf 0, um Testversionen wieder zu deaktivieren.

2. Einen Kunden eine Testversion anfordern lassen

POST /v1/trial ist öffentlich (keine Auth) und CORS-offen, sodass ein Browser-Formular auf Ihrer Marketing-Website direkt dorthin posten kann:

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
}

Die Antwort bestätigt, dass die Testversion ausgestellt und per E-Mail versendet wurde — sie enthält bewusst nicht den Schlüssel (kein Feld key, tier oder seats). Keyright sendet den Testschlüssel per E-Mail an die Adresse; der Kunde gibt ihn dann in Ihre App ein, wo er genau wie ein bezahlter Schlüssel aktiviert wird.

FeldErforderlichHinweise
productjader Produkt-Slug
emailjadie Testversion ist an diese Adresse gebunden
companyneinwird zum Lizenznehmer-Namen; Standard ist die E-Mail-Adresse
tenantneinnur nötig, wenn derselbe Slug in mehr als einem Mandanten existiert, zur Unterscheidung

Eine Testversion pro E-Mail-Adresse und Produkt. Eine erneute Anfrage mit derselben E-Mail-Adresse liefert denselben Schlüssel (created:false), statt einen neuen auszustellen — idempotent und missbrauchsresistent, sodass ein Neuladen oder ein zweiter Klick nie die Uhr zurücksetzt oder Testversionen stapelt.

Antworten:

StatusWann
200Testversion ausgestellt (oder die bestehende zurückgegeben)
400email/product fehlt oder ist ungültig, oder der Slug existiert in mehr als einem Mandanten (tenant übergeben)
403Testversionen sind für dieses Produkt nicht aktiviert (trialDays <= 0)
404unbekanntes Produkt

Einen Button „Kostenlose Testversion starten“ anbinden

Da /v1/trial CORS-offen ist, kann eine statische Seite es mit fetch aufrufen:

<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();
  // Der Schlüssel wird per E-Mail gesendet, nicht zurückgegeben — bitten Sie den Kunden, sein Postfach zu prüfen.
  if (res.ok) show(`Check ${userEmail} for your trial key — it expires ${data.expiresUtc}.`);
  else show(data.error);
};
</script>

In Ihrem Code

Der Kunde erhält den Testschlüssel per E-Mail und gibt ihn dann in Ihre App ein — wo er genau wie ein bezahlter Schlüssel aktiviert wird, ohne separaten Codepfad für Testversionen. Sie übergeben ihn wie jeden bezahlten Schlüssel an activate(). Mit Nebula zum Beispiel:

nebula register --key LIC-XXXXXXXXXXXXXXXXXXXX

Da ein Testschlüssel über genau denselben Aufruf aktiviert wird wie ein bezahlter Schlüssel, gibt es keinen separaten Codepfad für Testversionen zu schreiben — das Aktivierungs-Snippet für .NET, Node.js, Python, Java und rohes HTTP ist der Block für alle Sprachen in Aktivieren, deaktivieren & Plätze verschieben; übergeben Sie ihm den Testschlüssel unverändert. Die obige CLI-Form führt eine Online-Aktivierung durch (POST /v1/activate), bindet die Maschine und liefert einen signierten Lease mit trial:true und dem Ablaufdatum der Testversion. Ihre App liest das aus LicenseInfo: IsTrial == true, ExpiryUtc ist das Ende der Testversion, und DaysRemaining zählt herunter. Zeigen Sie das Evaluierungs-Banner an (z. B. „Enterprise Trial — 27 days left“) und schalten Sie hinter info.IsTrial, was immer Sie möchten. Dank des zwischengespeicherten Lease arbeitet die App offline weiter, bis die Testversion abläuft; mit dem Ablauf lässt sich der Lease nicht mehr validieren, und die App fällt fail-closed in den kostenlosen/unlizenzierten Zustand zurück (siehe .NET-SDK-Integration).

Testversionen berücksichtigen die Dauer ab der ersten Aktivierung und erkennen Uhrmanipulation — ein Kunde kann durch Zurückstellen der Uhr keine Zeit zurückgewinnen. Der Wechsel von Testversion zu bezahlt ist nahtlos: Wenn der Kunde kauft und einen Nicht-Test-Schlüssel aktiviert, ersetzt dieser die verbleibende Testversion ohne Neuinstallation. Die vollständige Aktivierungsform für Test-, befristete und unbefristete Schlüssel finden Sie in Aktivieren, deaktivieren & Plätze verschieben.

Offline-Testversionen für netzwerkisolierte Evaluatoren

Self-Service-Testversionen nutzen den Online-Pfad, aber das ist nicht die einzige Möglichkeit zu testen. Für einen netzwerkisolierten (air-gapped) oder Enterprise-Evaluator können Sie auch eine signierte, zeitlich begrenzte Offline-Testlizenzdatei ausgeben — ganz ohne Netzwerk. Mit der CLI von Nebula:

nebula license --sign --trial --tier enterprise --expiry 2026-10-23 \
  --licensee "Acme Corp" --private-key ./keys/nebula.private.json --out acme-trial.json

Die Datei trägt das Flag trial und ein expiryUtc; das SDK validiert sie gegen den eingebetteten öffentlichen Schlüssel und behandelt sie bis zum Ablauf als Testversion. Das ist das Offline-Gegenstück zum obigen Self-Service-Ablauf — dieselbe Testversions-Semantik, als Datei statt als Aktivierung ausgeliefert. Siehe Offline / netzwerkisoliert betreiben.

Cloud vs. Self-Hosting

Zwischen Keyright Cloud und selbst gehostet ändern sich nur zwei Dinge: die $BASE-URL (Cloud ist https://keyright.delta1labs.com) und woher $TOKEN stammt. Ein Punkt ist tatsächlich modusabhängig:

  • Self-Service-Testversionen benötigen SMTP. Keyright stellt den Testschlüssel per E-Mail zu, daher muss auf der Instanz SMTP konfiguriert sein (KEYRIGHT_SMTP_*) — ohne SMTP wird die Testversion zwar ausgestellt, aber der Kunde erhält den Schlüssel nie. Auf Keyright Cloud ist der E-Mail-Versand bereits eingerichtet; bei Self-Hosting konfigurieren Sie ihn selbst.
  • Der Pfad über die Offline-Testdatei benötigt überhaupt kein SMTP (und kein Netzwerk).

Prüfen

  1. Aktivieren Sie Testversionen für das Produkt (days > 0) und senden Sie dann POST /v1/trial mit einer Test-E-Mail-Adresse — erwarten Sie 200 mit "emailed": true und einem expiresUtc.
  2. Prüfen Sie das Postfach auf den Testschlüssel und bestätigen Sie, dass die Ansicht Licenses des Dashboards jetzt eine Testlizenz für diese E-Mail-Adresse zeigt.
  3. Aktivieren Sie den Schlüssel in Ihrer App und bestätigen Sie, dass sie das Evaluierungs-Banner mit IsTrial == true und einem herunterzählenden DaysRemaining anzeigt.
  4. Fordern Sie die Testversion mit derselben E-Mail-Adresse erneut an — erwarten Sie denselben Schlüssel zurück und "created": false (keine neue Lizenz, keine zurückgesetzte Uhr).

Siehe auch