Skip to main content
Para despliegues posteriores al primer registro del mismo email, puede saltarse el navegador y usar la activación automática por email — una sola llamada de API. El flujo de abajo sigue siendo necesario en el primer registro de un email.

Visión general del flujo

Diagrama del flujo de activación manual: la instancia llama a register/init, muestra la URL, el operador se autentica en el navegador, la instancia hace polling, recibe la api_key, activa con HMAC y continúa con los heartbeats. La URL base se define en la variable LICENSE_BASE_URL del .env del producto (predeterminado: https://license.evolutionfoundation.com.br).

Paso 1 — Iniciar el registro

Cuando la instancia detecta que no hay api_key guardada localmente, llama:
Campos: Respuesta (200):
El token expira en 30 minutos. Hay rate limit de 10 inits por hora por IP. Si el operador no completa la activación a tiempo, basta repetir el paso 1.
Errores posibles:

Paso 2 — Mostrar la URL al operador

La instancia muestra register_url al operador. Patrones aceptados:
  • Web UI / Manager — botón “Activar Licencia” abre el link en el navegador
  • Terminal / CLI — imprime la URL y queda esperando
  • QR Code — en despliegues headless, genera un QR para escanear
Ejemplo de salida en CLI:

Paso 3 — Qué ocurre en el navegador

El servidor de licencia renderiza la página de registro con la identidad visual de Evolution. El operador elige entre:
  • Magic Link — informa nombre + email, recibe link de confirmación por email
  • Google OAuth — login con cuenta Google
  • GitHub OAuth — login con cuenta GitHub
Tras autenticar, el servidor crea (o recupera) el customer y genera un authorization_code interno. Este flujo es transparente para la instancia — solo necesita hacer polling.

Paso 4 — Polling del estado

Mientras el operador resuelve el login, la instancia hace polling:
Mientras está pendiente:
Al completarse:
Tras expirar:
Recomendaciones de implementación:
  • Intervalo de polling entre 3 y 5 segundos (no más rápido)
  • Timeout total de 30 minutos
  • Al recibir completed, persistir api_key en ubicación segura (config cifrada, secret manager, etc.)

Paso 5 — Activar la instancia

Con la api_key en mano, la instancia llama al endpoint de activación:
Respuesta:
La geolocalización (operator_country, operator_city) es detectada automáticamente desde la IP de la request. La instancia no envía esa información.

Paso 6 — Heartbeat periódico

Tras la activación, la instancia envía heartbeats cada 5 minutos:
El campo telemetry_bundle es JSON libre. Los campos extraídos automáticamente por el servidor están detallados en Telemetría.

Paso 7 — Desactivación (opcional)

En apagado controlado (uninstall, container stop intencional), se recomienda:
Esto libera el conteo de la instancia en el licenciamiento. No es obligatorio — el servidor expira instancias inactivas automáticamente tras 7 días sin heartbeat.

Autenticación HMAC

Todas las llamadas a /v1/activate, /v1/heartbeat y /v1/deactivate requieren el header X-Signature con HMAC-SHA256 del body. Algoritmo:
  1. Serializar el body como JSON
  2. Calcular HMAC-SHA256(body, api_key)
  3. Convertir a hexadecimal
  4. Enviar en el header X-Signature
El body usado en el HMAC debe ser idéntico byte a byte al enviado. No reformatee el JSON entre la firma y el envío.

Ejemplo Python

Ejemplo Node.js

Ejemplo Go


Códigos de error


Checklist de integración

Para quien implementa la activación en un fork o producto derivado:
  • Generar y persistir instance_id (UUID v4) en la primera ejecución
  • Implementar POST /v1/register/init cuando no hay api_key
  • Mostrar register_url al operador (UI, terminal o QR)
  • Polling GET /v1/register/status cada 3–5s
  • Persistir api_key en ubicación segura (no en texto plano)
  • Implementar HMAC-SHA256 para todas las llamadas firmadas
  • POST /v1/activate al iniciar el servicio
  • POST /v1/heartbeat cada 5min con messages_sent + features
  • POST /v1/deactivate en apagado controlado
  • Manejar errores (token expirado, key suspendida, límite de instancias)
  • Backoff exponencial en fallos transitorios de red

Modo offline y degradación

Si el servidor de licencia es inaccesible:
  • La instancia sigue funcionando normalmente
  • Los heartbeats fallan silenciosamente (sin romper la aplicación)
  • Tras reconectarse, el siguiente heartbeat retoma el ciclo
La activación inicial (pasos 1–5) es la única etapa que exige conectividad. Después de eso, la instancia tolera períodos offline. Vea FAQ — modo offline para más detalles.