Skip to content

Guía

Pruebas gratuitas de autoservicio

Reparte claves de prueba con tiempo limitado sin intervención del proveedor — los clientes obtienen por sí mismos una prueba desde tu propio sitio, y tu aplicación la activa exactamente igual que una clave de pago.

Keyright puede repartir claves de prueba con tiempo limitado para un producto sin intervención del proveedor: un cliente hace clic en “Iniciar prueba gratuita” en tu sitio, Keyright acuña una licencia de prueba, le envía la clave por correo y tu aplicación la activa exactamente igual que una clave de pago. Las pruebas están desactivadas por defecto — un producto las ofrece solo una vez que te adhieres estableciendo una duración de prueba.

A lo largo de la página, $BASE es la URL de tu servicio de emisión y $TOKEN es un token de administración de inquilino (consulta Primeros pasos).

1. Habilitar las pruebas en un producto

Una prueba se define por tres cosas: días (duración; <= 0 la desactiva), nivel (el nivel de características que otorga la prueba) y puestos. Establécelos en un producto existente:

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 }

O establécelos al crear el producto (trialDays, trialTier, trialSeats en 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 devuelve los trialDays/trialTier/trialSeats de cada producto, y la pestaña Products del panel expone el mismo conmutador. Pon days en 0 para volver a desactivar las pruebas.

2. Un cliente solicita una prueba

POST /v1/trial es público (sin autenticación) y abierto a CORS, de modo que un formulario de navegador en tu sitio de marketing puede hacerle POST directamente:

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 respuesta confirma que la prueba se emitió y se envió por correo — deliberadamente no contiene la clave (ningún campo key, tier ni seats). Keyright envía por correo la clave de prueba a la dirección; el cliente la introduce luego en tu aplicación, donde se activa exactamente igual que una clave de pago. Por tanto, las pruebas de autoservicio requieren SMTP configurado en la instancia (KEYRIGHT_SMTP_*) para entregar la clave — sin él la prueba se acuña pero el cliente nunca recibe la clave.

CampoObligatorioNotas
productsíel slug del producto
emailsíla prueba queda asociada a esta dirección
companynose convierte en el nombre del licenciatario; por defecto es el correo
tenantnosolo necesario si el mismo slug existe en más de un inquilino, para desambiguar

Una prueba por correo por producto. Volver a solicitar con el mismo correo devuelve la misma clave (created:false) en lugar de acuñar una nueva — idempotente y resistente al abuso, de modo que un refresco o un segundo clic nunca reinicia el reloj ni acumula pruebas.

Respuestas:

EstadoCuándo
200prueba emitida (o se devuelve la existente)
400email/product faltante o inválido, o el slug existe en más de un inquilino (pasa tenant)
403las pruebas no están habilitadas para ese producto (trialDays <= 0)
404producto desconocido

Conectar un botón “Iniciar prueba gratuita”

Como /v1/trial está abierto a CORS, una página estática puede invocarlo con 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();
  // The key is emailed, not returned — tell the customer to check their inbox.
  if (res.ok) show(`Check ${userEmail} for your trial key — it expires ${data.expiresUtc}.`);
  else show(data.error);
};
</script>

3. El cliente activa la prueba

El cliente recibe la clave de prueba por correo y luego la introduce en tu aplicación — donde se activa exactamente igual que una clave de pago, sin una ruta de código de prueba aparte (se la pasas a activate() como a cualquier clave de pago). Con Nebula, por ejemplo:

nebula register --key LIC-XXXXXXXXXXXXXXXXXXXX

Esto realiza una activación en línea (POST /v1/activate), vincula el equipo y devuelve un lease firmado con trial:true y el vencimiento de la prueba. La aplicación lo refleja en la interfaz (p. ej. “Prueba Enterprise — 27 días restantes”) y, gracias al lease en caché, sigue funcionando offline hasta que expire la prueba. Al vencer, el lease deja de validar y la aplicación falla de forma cerrada al estado gratuito/sin licencia (consulta Integración del SDK de .NET).

De prueba a pago es fluido: cuando el cliente compra y activa una clave que no es de prueba, esta sustituye a la prueba restante sin reinstalar.

4. Pruebas offline para evaluadores aislados

Las pruebas de autoservicio usan la ruta en línea, pero esa no es la única forma de probar. Para un evaluador aislado o corporativo también puedes repartir un archivo de licencia de prueba offline firmado y con tiempo limitado — sin necesidad de red en absoluto. Con 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

El archivo lleva el indicador trial y un expiryUtc; el SDK lo valida contra la clave pública integrada y lo trata como una prueba hasta que expira. Este es el análogo offline del flujo de autoservicio anterior — la misma semántica de prueba, entregada como archivo en lugar de como activación.

Véase también