Añade licencias a tu software

Calcula unos 15 minutos para proteger una exportación: configuración, ejemplo, integración y prueba de denegación. Las herramientas del lenguaje deben estar instaladas.

El SDK gestiona solicitudes, identidad, firmas, credenciales, caché y latidos. Proporciona la clave del cliente y tu función; no necesitas HTTP manual ni guardar activation_id.

1. Descargar paquete de integraciónGenera la configuración del producto en la consola
2. Generar un archivo exportadoComprobar autorización y resultado
3. Integrar en la aplicaciónInicio, entrada de negocio, cierre

1. Prepara el paquete en la consola

Abre Inicio rápido, indica el nombre del software, elige licencia vinculada o flotante y crea el producto para continuar. El sistema prepara producto, política, licencia de prueba, clave pública y versión 1.0.0. Elige un lenguaje, descarga el paquete configurado y extráelo.

El paquete contiene dos configuraciones:sdk-demo.json contiene una clave de prueba para tus pruebas;product.json contiene solo configuración del producto y clave pública, y puede distribuirse con el software.

Para empezar, elige licencia vinculada al dispositivo. El ejemplo incluye export sin contador. Los productos existentes necesitan esa función en la política y licencia.

2. Comprueba el entorno y exporta un archivo

Abre un terminal en la raíz extraída. Conserva juntos product.json, sdk-demo.json, start.ps1, start.sh y sdk. Elige lenguaje y sistema y ejecuta. La comprobación no envía activaciones.

Resultado esperado:Código 0, salida indicada y un nuevo licensed-report.txt. Ejecuta sin la opción de prueba: el SDK restaura la credencial sin ocupar otra plaza de dispositivo.

License OK: export is available
Export completed: licensed-report.txt

Instala las herramientas que falten. C/C++ necesita archivos de desarrollo de libcurl; MinGW acepta -CurlRoot. Aceptar una advertencia del navegador no basta: el entorno debe confiar en el certificado del servidor de prueba.

3. Intégralo en la aplicación del cliente

Ejecuta el instalador en tu proyecto. Los nueve lenguajes usan 0.10.0. Verifica SHA-256 antes de instalar o extraer. Añade solo product.json a los recursos.

Archivo ejecutable para este lenguaje:. Copia su punto de entrada de negocio a tu proyecto; Ver el código completo →

4. Verifica que la denegación impide exportar

Confirma que la política excluya licentivo_denied_probe y ejecuta el comando. Debe salir con código distinto de cero sin crear denied-report.txt. Usa una ruta que aún no exista.

5. Añade operaciones medidas cuando sea necesario

Pasa tu función y un ID estable a RunMeteredFeature. El SDK reserva uso, confirma el éxito, cancela si falla la operación y registra confirmaciones pendientes.Consulta la integración medida y los reintentos →

Distingue estos tres identificadores

Configura por separado el intervalo de heartbeat y la duración sin conexión en Políticas de licencia. La validez empieza en la primera activación. Añade cuotas de funciones, puestos flotantes y activación por archivo cuando funcione la integración básica.

Sin registrarte puedes abrir Probar la demostraciónpara ver solicitudes y respuestas. Para automatizar la emisión, continúa con Clave API de gestión.

SDK cliente

Entrega tu función al SDK: RunFeature para permisos, RunMeteredFeature para contadores. El SDK gestiona solicitudes, firmas, caché y latidos.

Antes de ejecutar

En la consola, Inicio rápidodescarga el paquete configurado. La demo usa el archivo privado sdk-demo.json; en la aplicación real usa product.json, con la clave del cliente al iniciar. Descargar SDK proporciona código genérico sin la configuración de tu producto.

{
  "base_url": "https://www.licentivo.com",
  "product_id": "PRODUCT_UUID",
  "license_key": "",
  "device_name": "Customer app",
  "app_version": "1.0.0",
  "trusted_keys": {
    "SIGNING_KEY_UUID": "BASE64URL_PUBLIC_KEY"
  },
  "timeout_seconds": 10,
  "allow_http": false
}

Elige tu lenguaje

Este código coincide con el archivo distribuido y genera una exportación real. Las variables sustituyen la entrada de activación; usa tu interfaz y mantén client durante la aplicación.

Ejecuta la operación protegida con el SDK y cierra client al salir.

正在加载代码…

Ejecutar un ejemplo de aplicación

Los ejemplos incluyen activación, estado, exportación y liberación del dispositivo. Java, Python y C# tienen ventanas; los demás, menús de terminal. Introduce la clave una vez y luego déjala vacía.

Una exportación correcta crea licensed-report.txt. Configura la cuota de export en la política antes de medir su uso.

Las demos de ventana y menú muestran reservas de bajo nivel. Usa RunMeteredFeature: los nueve lenguajes guardan confirmaciones pendientes. Si falla durante la operación, revisa tu propio resultado.

¿Cómo mostrar el estado de autorización?

Status y FeatureStatus leen localmente sin solicitudes ni esperar la verificación. Usa avisos de estado para actualizar la interfaz.

allowed indica validez local; las funciones medidas siguen solicitando unidades. lease_valid_until es el plazo de la caché firmada, no del final de la licencia. code, request_id y retryable indican error, referencia del registro y posibilidad de reintento.

Consulta sdk/README.md para métodos, callbacks y paquetes. El sitio ofrece paquetes versionados e instaladores comunes; la publicación en registros sigue pendiente.

¿Dónde va esto en tu aplicación?

Los nombres indican operaciones; usa los métodos exactos de tu lenguaje. Para heartbeats, caché y actualización en línea, consulta Heartbeats y acceso sin conexión.

Clave API de gestión

Usa una API Key de gestión para emitir licencias desde tu sistema de pedidos o leer datos de autorización desde un servidor. Representa tu espacio de proveedor.

¿Qué clave necesita el cliente?

Para validar la autorización del software cliente basta una clave de licencia. La API Key de gestión controla todo el espacio; no la incluyas en software cliente ni páginas públicas.

Crear una clave

1. Entra como Owner del espacio y abre API Key y pulsa Crear API Key.
2. Pon un nombre según su uso, como “Pedidos”. Elige Solo lectura para consultar o Lectura/escritura para crear o modificar licencias. Validez: 1–365 días.
3. Copia la Key completa al guardar; solo se muestra una vez. Guárdala en la configuración privada del servidor o una variable de entorno.

Enviar la primera petición de gestión

Este ejemplo lee la lista de productos. Configura LICENTIVO_URL con la URL del servidor de licencias y configura LICENTIVO_API_KEY con la clave completa recién creada y ejecuta:

curl "$LICENTIVO_URL/api/v1/products?limit=25" \
  -H "Authorization: Bearer $LICENTIVO_API_KEY"

Esta sintaxis es de Bash/macOS/Linux. En Windows PowerShell usa curl.exe; la variable de entorno es $env:LICENTIVO_URL y $env:LICENTIVO_API_KEY. Ejemplos completos en nueve lenguajes también en Opción API Key de gestión en la página SDK.

El éxito devuelve HTTP 200 con data.items. Peticiones Bearer Key sin cookie de sesión ni CSRF.

Permisos e invalidación

Las Keys de lectura consultan recursos; las de lectura/escritura crean y modifican productos, políticas y licencias. Cuentas, equipos, ajustes y pagos requieren iniciar sesión con permisos; no admiten Key de gestión.

Revoca en la consola una Key filtrada o sin uso. Para cambiarla, pulsa Rotar; la anterior se invalida de inmediato. Después actualiza tu servidor.

La cuota API del plan cuenta activación, validación, heartbeat y liberación. Estas peticiones de gestión no consumen esa cuota.

API de productos y licencias

Emite licencias desde tu servidor tras un pedido: crea el producto y la política, luego una licencia por cliente. Los dos primeros suelen configurarse una sola vez.

Crea primero en consola uno con escritura Clave API de gestión. Los ejemplos siguientes usan Authorization: Bearer 你的管理Key; conserva esta clave en el servidor del proveedor.

Para licencia limitada antes de activar,expires_at y first_activated_at son null. La vigencia empieza al activar; cambiar de equipo no la reinicia.

Gestión posterior

La paginación usa limit=25&offset=0, limit máximo 100. Otros parámetros y esquemas en Archivo OpenAPI; consulta el tema de la izquierda para cada modelo.

Llamadas de licencia del SDK

Elige lenguaje y operación y llama al SDK. Gestiona activación, identidad del dispositivo, firmas, caché, latidos y reserva, confirmación y cancelación de uso.

En los ejemplos, client procede del inicio, path es la ruta de exportación y exportReport / export_report es tu función. jobID es el ID estable guardado por la aplicación.

Ver el código completo → · Inicio rápido · Consulta la integración medida y los reintentos →

Heartbeats y acceso sin conexión

Ambos ajustes están en Políticas de licencia, pero definen cosas distintas: frecuencia de contacto online y tiempo de uso sin alcanzar el servidor.

Intervalo: frecuencia de validación

Configura Intervalo de heartbeat (segundos) en 600, el SDK envía un heartbeat aproximadamente cada 10 minutos mientras se ejecuta. Cada éxito obtiene las reglas actuales y actualiza la caché local de licencia.

Introduce 600–86400 segundos. Introduce 0 desactiva los latidos programados. La aplicación puede verificar o actualizar manualmente. Se añade un retraso aleatorio del 0–10%; el intervalo nunca baja de 600 segundos.

Con una licencia ligada al dispositivo y caché válida, se restaura el acceso y se actualiza en segundo plano, incluso sin temporizador. Las licencias solo online y flotantes esperan al servidor.

Plazo sin conexión: uso sin alcanzar el servidor

El modo sin conexión tiene tres opciones. No cambia el intervalo de heartbeat.

Permitir durante un tiempo definido

Con 24 horas, la caché firmada dura como máximo 24 horas desde la última validación online correcta. Puede funcionar durante cortes de red o fallos temporales en ese plazo. Después necesita una validación online correcta.

Respaldo sin conexión no permitido

El inicio requiere conexión correcta al servidor; la caché de disco no permite omitir un fallo. La firma breve obtenida durante la ejecución dura como máximo max(10, 心跳间隔) segundos; la aplicación debe seguir validando y comprobando permisos.

Permitir uso sin conexión permanente

La firma local puede usarse a largo plazo, incluso sin red. Una licencia de 30 días caduca en 30 días; offline permanente no convierte una licencia temporal en perpetua.

La API usa offline_mode representa estas tres opciones, en orden limited, none, permanent. Con un plazo sin conexión,offline_seconds es 1–31536000 segundos; usa 0 en los otros dos modos.

¿Cómo funcionan estas combinaciones?

Deja más tiempo offline que el intervalo de heartbeat. Con heartbeat cada hora y solo 1 minuto offline, la firma caduca antes del siguiente; la app debe validar aparte.

¿Cambiar la política actualiza las licencias existentes?

Sí. Los ajustes de heartbeat u offline se aplican a licencias vinculadas antiguas y nuevas en la próxima activación, validación o heartbeat correcto. El SDK sustituye la caché firmada. La misma Idempotency-Key sigue devolviendo el resultado original.

Un dispositivo offline sigue con sus reglas firmadas. Reconectarse no actualiza la caché por sí solo: una petición debe completarse. La app puede refrescar al volver la conexión.

Actualización online explícita

Estos métodos siempre intentan el servidor, incluso con offline permanente y heartbeat desactivado. El éxito renueva la firma. Un fallo de red informa error y conserva caché válida. Una revocación o liberación explícita la borra.

Un refresco correcto cuenta como una petición de activación API. Si la política activa heartbeats antes desactivados, llama StartHeartbeat de tu lenguaje. Los dispositivos offline no reciben revocaciones ni liberaciones.

Vinculación de dispositivos

Con una licencia de un dispositivo, copiar el software y la caché a otro equipo normal no transfiere la autorización original.

¿Cómo identifica el SDK el equipo?

Al iniciar, el SDK lee la identidad del sistema y calcula un hash con el ID del producto. La firma del servidor incluye ese hash y la validación local también lo comprueba.

Windows lee MachineGuid, Linux machine-id y macOS IOPlatformUUID. Solo se envía el hash calculado, no la identidad original. El campo antiguo de configuración device_id no reemplaza la identidad local real.

¿Qué pasa si se copian los archivos de A a B?

1. A activa y recibe firma vinculada al hash de A.
2. B lee identidad propia, obtiene otro hash y rechaza caché de A.
3. B debe activarse online. Con límite de un dispositivo y A aún vinculado, el servidor rechaza B.

¿Cómo cambia de equipo el cliente?

El cliente desvincula el equipo antiguo y activa el nuevo. Si el antiguo se averió, libéralo en Activaciones de dispositivos de la consola. El cambio no reinicia la caducidad.

Reinstalar el sistema puede cambiar su identidad y exigir activar un dispositivo nuevo. Clonar todo el sistema, falsificar identidad o modificar el cliente son ataques más fuertes; este hash por sí solo no garantiza impedirlos.

Con offline prolongado, la firma de A no sabe al instante que se liberó. Necesita una petición correcta al servidor para actualizar ese estado. Más tiempo offline retrasa las restricciones remotas.

SHA256(UTF8(
  "LicenovaDevice/v2\n"
  + lower(product_id) + "\n"
  + lower(trim(OS_machine_identity))
))

Cuotas y facturación

La cuota de dispositivos cuenta equipos usados; la API, peticiones correctas. Son medidas distintas; el número de equipos no determina llamadas API.

¿Qué operaciones consumen cuota API?

¿Las peticiones repetidas cuentan varias veces el dispositivo?

No. En un periodo, el mismo dispositivo del mismo producto cuenta una vez, pero cada heartbeat correcto cuenta como API. Liberarlo no borra usos anteriores.

Ejemplo: 100 dispositivos, 8 horas al día, 22 días al mes, heartbeat cada 10 minutos. Solo los heartbeats generan 105.600 llamadas. Añade 100 activaciones y una validación extra por equipo al día, sumando 107.900 llamadas.

Las validaciones extra son supuestas; el uso real depende de la app. En Estimación de uso conectado ajusta equipos, duración e intervalo.

¿Cómo se cobra el exceso del plan?

Con 100.000 llamadas y 0,0001 USD por extra: 120.000 llamadas correctas generan 20.000 extra y un cargo API de 2 USD.

El exceso permitido descuenta saldo al precio del administrador. Redondea el acumulado a céntimos y cobra solo el incremento, evitando cargos repetidos por redondeo de precios pequeños.

El exceso de dispositivos va aparte: dispositivos extra × precio unitario. Un límite estricto rechaza exceso; saldo insuficiente rechaza la siguiente petición de pago. Rechazos no suman uso.

API ilimitada no genera exceso. Cero significa ninguna llamada gratis; el exceso se aplica desde el primer éxito. Cuotas, precios y límites en Plan actual, estas cifras son solo ejemplos.

¿Cuándo empiezan la vigencia y la cuota?

Compre 1, 3, 6 o 12 meses. Pague el total una vez; el plan empieza tras el pago.

Las cuotas se renuevan mensualmente desde la activación. Inicio el 31 de enero: último día de febrero y luego 31 de marzo. Sin acumulación.

Sin compra, rigen ajustes del administrador por mes natural UTC. Dispositivos usan factura mensual; exceso API descuenta saldo al instante. Al comprar, usa cuotas del periodo propio sin sumar las predeterminadas.

Un rechazo por cuota o saldo no invalida firmas offline, que siguen sus reglas originales. El proveedor libera dispositivos en la consola sin consumir cuota API de ejecución.

Puestos flotantes

La licencia flotante limita programas simultáneos. Permite compartir el software por turnos sin comprar una licencia por equipo.

Ejemplo

Con 100 equipos y 10 plazas, arrancan los primeros 10 programas; el 11 recibe “Sin plazas”. Al salir y cerrar el SDK normalmente, otro puede tomar la plaza. Dos programas en un equipo consumen dos plazas.

Configura en la política

Elija asientos flotantes con límite 10. Heartbeat mínimo: 600 s; la concesión debe durar más, por ejemplo 1200 s. El heartbeat renueva; tras fallo o desconexión, el vencimiento libera el asiento.

La licencia flotante permite cortes breves dentro del alquiler. El tiempo offline también está limitado por este; no admite offline permanente ni primera activación offline por archivo.

¿Qué más debe gestionar el código?

Usa Open/Start y cierre normal. El SDK crea un ID de sesión por client. No crees uno por exportación; conserva uno hasta salir del programa.

La caché flotante antigua no restaura la plaza al reiniciar. Si caducó el alquiler, activa otra vez y consigue plaza antes de trabajar.

Activación sin conexión

Para un equipo totalmente offline, usa un archivo de solicitud y respuesta firmada para la primera activación. Lleva la solicitud por USB a un equipo online.

Pasos

1. En el equipo destino, carga la configuración, llama OfflineRequest("activate") y guarda el archivo. Crearlo no contacta al servidor.
2. En un equipo online, abre Activación por archivo offline, sube la solicitud y descarga la respuesta. El cliente final también puede usar su portal.
3. Lleva la respuesta al equipo y llama ImportOffline con solicitud y respuesta originales. El SDK verifica firma, ID, versión e identidad local y guarda la caché.
4. Comprueba autorización con CheckFeature. Un equipo offline no necesita heartbeat online; la política define el tiempo offline.

La activación por archivo solo admite licencias vinculadas con offline permitido. La solicitud dura 30 días. La licencia temporal comienza al aprobar el servidor, que no sabe cuándo se importa la respuesta.

¿Cómo desactivo sin conexión?

En el equipo original, genera OfflineRequest("deactivate"). El SDK borra primero la caché; entrega la solicitud al proveedor o portal. Borrar no prueba que no existan copias antiguas. Para detener pronto, exige validación online periódica.

Nombres por lenguaje

En C, libera el texto devuelto con ln_free_string. Pasa el contenido real del archivo de respuesta, no el envoltorio data de la API web.

Límites de uso de funciones

Permitir exportar difiere de 500 exportaciones mensuales. RunFeature comprueba permisos; RunMeteredFeature confirma el uso tras el éxito.

Permitir 500 exportaciones al mes

Añade export a las funciones y una cuota: export, 500, Mensual. Por defecto rechaza al agotarse. Para exceso, fija su máximo; el sistema registra usos extra para tu sistema de pedidos.

Cuotas diarias y mensuales reinician a medianoche UTC; las acumuladas no. Cambiar límites no borra usos consumidos.

Confirmar el uso tras una exportación correcta

Pasa tu función al SDK. Cada tarea nueva necesita otro ID; los reintentos conservan ID, función y cantidad. No ejecutes el mismo ID simultáneamente en distintos procesos.

Configura primero la cuota export. Añade -Metered -OperationID export-job-001 en Windows o --metered --operation-id export-job-001 en Linux/macOS.

¿Cómo interpretar los campos de respuesta?

Consulta los cuerpos, respuestas y tipos de campo de Reserve, Commit y Cancel en la referencia de la API.

Consume sigue descontando de inmediato. Usa reservas para no contar trabajos fallidos. Todos los endpoints de uso requieren conexión y quedan fuera de las cuatro operaciones API facturables de la plataforma.

Versiones y mantenimiento

Comprar de forma perpetua permite seguir usando, pero no siempre actualizar gratis para siempre. El mantenimiento decide qué versiones corresponden según su fecha de publicación.

Comprar versión actual, un año de actualizaciones incluido

Fija Perpetua y 365 días de mantenimiento desde la primera activación. Publica 1.0.0, 1.1.0, etc. en Versiones del software con fechas reales.

Las versiones publicadas durante mantenimiento siguen usándose. Las posteriores se rechazan; las antiguas funcionan. Tras renovar, amplía mantenimiento en Derechos y cliente de la licencia.

¿Cómo informa la app su versión?

Pon app_version en sdk-demo.json, como 1.1.0. Con mantenimiento, publícalo antes en la consola. Solo acepta tres números como 1.2.3. La fecha publicada no cambia para proteger derechos vendidos.

Para permitir solo 1.x, fija 1.0.0–1.999.999 sin mantenimiento. Tras actualizar, consigue online una firma para la versión nueva; la caché antigua no la autoriza.

Ofrecer descargas

Los registros incluyen URL HTTPS y SHA-256 opcionales. El portal solo muestra versiones elegibles. Proporcionan enlaces; no suben instaladores ni instalan actualizaciones automáticamente.

Portal del cliente

Los clientes consultan licencias, dispositivos y desvinculan sin entrar en la consola del proveedor.

El proveedor vincula primero el correo del cliente

Introduce correo al emitir o en Derechos y cliente. Envía el Portal del cliente al cliente. Ese email recibe un enlace de acceso de un uso, válido 15 minutos. La sesión dura 24 horas.

El cliente solo ve licencias de ese email, no productos, facturas ni datos de otros clientes. Configura primero el correo en los ajustes del administrador.

¿Y si el cliente perdió la clave al cambiar de equipo?

1. El cliente introduce el email asociado a la licencia y abre el enlace recibido. El enlace solo inicia sesión; no desvincula dispositivos.
2. En Mis equipos/sesiones, elige antiguo, Desvincular y transferir, confirma.
3. La página muestra un código temporal, válido hasta 15 minutos y una activación correcta. El cliente puede copiarlo o pedir envío a su email.
4. Abre tu app en el nuevo equipo e introduce el código temporal. El SDK identifica el equipo, vincula la licencia original y guarda la credencial. Reinicios y heartbeats usan esa credencial; caducar el código no afecta la activación.

Solo cambia el vínculo del dispositivo. Se conservan ID, caducidad original, funciones, cliente y usos consumidos; no se emite otra licencia. El equipo nuevo debe cumplir la política original y tener una plaza libre.

¿Qué debe cambiar el proveedor del software?

Actualiza al SDK actual. El campo de clave de licencia también acepta lv_tmp_ códigos temporales; pon uno en license_key es suficiente; Start, validación y latidos funcionan igual. El SDK guarda la credencial del dispositivo en una caché privada;cache_path puede quedar vacío. Guarda el archivo en los datos del usuario actual; no lo distribuyas con el instalador.

Tras canjear, la app puede borrar license_key vacío; mantén producto, claves y cache_path, el SDK restaura la credencial al reiniciar. El cliente no necesita guardar ni repetir el código temporal. Conserva la entrada hasta que el canje se complete para reintentar tras una desconexión.

Si el código caduca o se cierra la página

Vuelve al portal para ver códigos sin usar. Si uno caducó, pide otro junto al equipo liberado sin consumir otro traslado. Un código usado no se canjea otra vez ni se obtiene del registro viejo para evitar límites. Para otro traslado desvincula el equipo activo actual.

Si el nuevo equipo está totalmente sin conexión

Introduce el código en el equipo nuevo y exporta la solicitud con el SDK. Antes de caducar, consigue la respuesta en el portal desde un equipo online e impórtala en el nuevo. La política debe permitir activación offline vinculada. Sigue el plazo original; protege la respuesta con autorización y credencial del equipo.

Límites de desvinculación y equipo anterior

Fija el límite por licencia y mes UTC. Cero desactiva nuevas desvinculaciones del portal. Clics repetidos, consultar códigos y reemitir códigos caducados sin usar no suman. Cubre portal y solicitudes offline del cliente, no liberaciones manuales del proveedor ni llamadas con la clave original.

Desvincular remotamente bloquea la siguiente validación online. La caché antigua sigue hasta conectar o caducar. La caché permanente no puede detenerse al instante a distancia; usa validación periódica si necesitas revocar pronto. Copias normales de configuración, credencial y caché en otro equipo se rechazan por identidad distinta.

El portal gestiona el uso de licencias. Los pedidos y cobros de software siguen en el sistema del proveedor.

Notificaciones de eventos

Al activar, renovar o revocar una licencia, Licentivo puede avisar a tu servidor para sincronizar pedidos, clientes y soporte.

Añadir destino de notificación

En Notificaciones de licencia añade URL HTTPS y eventos. El secreto de firma aparece una vez; guárdalo en el servidor receptor. En producción no se admiten destinos locales o privados.

Verifica la firma al recibir

Lee X-Licentivo-Timestamp, X-Licentivo-Event y cuerpo original. Une timestamp + '.' + ID de evento + '.' + cuerpo, calcula HMAC-SHA256 con el secreto, añade sha256= y compara X-Licentivo-Signature en tiempo constante. Rechaza más de 5 minutos de diferencia.

Evita duplicados por ID. Verifica firma, guarda el evento en transacción o cola y responde 2xx tras persistir. Duplicados reciben 2xx sin repetir acciones del pedido.

¿Qué ocurre si falla?

Hasta 8 intentos automáticos con pausas crecientes. La consola muestra estado HTTP, hora y errores y permite reenvío manual. Evento y operación comparten transacción; la entrega continúa al reiniciar.

Eventos: creación, actualización, renovación, revocación, activación, liberación, consumo, próxima caducidad, caducidad y mantenimiento. Solo incluyen prefijo de licencia, nunca la clave completa.

Operaciones en lote y cambios de política

Emite, renueva o revoca en lote para tratar clientes juntos. Previsualiza el impacto antes de cambiar derechos existentes.

Emitir en lote o importar

En Licencias, elige Emisión/importación en lote, producto y política. Introduce nombre y email por fila o CSV con customer,customer_email. Máximo 100 filas. Descarga resultados y guarda códigos completos.

Si falla un elemento, no se aplica el lote. Tras timeout, reintenta sin cambiar contenido; el ID devuelve el resultado original sin volver a emitir.

Renovar o revocar en lote

Selecciona licencias y pulsa Renovar o Revocar en lote. La casilla de cabecera selecciona la página; se mantiene al paginar, máximo 100. Filtros, salir o refrescar borran la selección.

Indica días adicionales. Sin activar aumenta duración; activa extiende vencimiento; caducada extiende desde ahora. Antes de revocar, despliega y verifica clientes. Es irreversible; miembros de lectura no pueden hacerlo.

Aplicar nueva política a licencias existentes

1. Guarda las nuevas reglas en Políticas de licencia.
2. Selecciona licencias de un producto, Aplicar política y la política nueva.
3. Revisa duración, dispositivos/plazas, funciones, usos y mantenimiento. Si plazas ocupadas superan el nuevo límite o quedan equipos activos al cambiar modo, resuélvelos primero.
4. Aplica tras confirmar. La siguiente validación online recibe autorización firmada nueva; la caché totalmente offline no cambia a distancia.

La vista previa dura 10 minutos. Si cambia licencia o política, repítela. La duración nueva recalcula caducidad desde la primera activación original; revisa fechas antes.

Preguntas frecuentes

Revisa el código de error y su configuración. En la respuesta, request_id ayuda a localizar en registros. No incluyas claves completas en registros/capturas.

¿Qué reviso si falla la activación?

Comprueba acceso al servidor, ID del producto, código completo y que la licencia sea de ese producto. Antes de desplegar, el equipo cliente no puede usar tu 127.0.0.1 ; esa dirección corresponde al propio equipo del cliente.

¿Por qué sigue funcionando sin conexión?

Offline, el SDK verifica localmente firma, producto, dispositivo, funciones y caducidad; solo omite la petición al servidor. Caché caducada o rechazo explícito de revocación/liberación impide seguir usando.

¿Por qué falla la firma o la comprobación del equipo?

Una clave pública distinta, caché de otro producto o copiada a otro equipo pueden causar fallos. Comprueba trusted_keys usa el ID y la clave pública del producto actual; comprueba después si se cambió o reinstaló el sistema.

SDK informa clock rollback : comprueba retroceso del reloj. Corrige y actualiza online.

Respuesta de error completa

{
  "error": {
    "code": "LICENSE_REVOKED",
    "message": "License was revoked"
  },
  "request_id": "99999999-9999-4999-8999-999999999999"
}

400/415: corrige campos o Content-Type; 401: revisa la Key; 403: trata el código de autorización; 409: cuota, sesión o conflicto de idempotencia; 429: espera según Retry-After. Reintenta timeout o 5xx con pausas. Para escrituras conserva ID y cuerpo originales para evitar doble conteo.

¿Cómo leo la respuesta JSON?

Respuesta correcta data y request_id; los fallos devuelven error.code, error.message y request_id. Conserva código de error y request_id para diagnosticar.

Para correo, pagos o despliegue, consulta Soporte y diagnóstico.