Skip to main content
No todas las instituciones compran lo mismo. Cada tenant tiene una lista de módulos habilitados (enabledProductModules), configurable en Institución → Capacidades, y esa lista decide tres cosas: qué se ve en la navegación, qué se ve en el portal, y qué endpoints responden.
Si un endpoint del Client API devuelve 403 MODULE_DISABLED, el token está bien: lo que falta es el módulo en la institución. Revisa platform_integrations y el módulo funcional del recurso que estás tocando.

El registro canónico

Los ids son estables y viven en packages/shared/src/product-modules/registry.ts. La API solo acepta subconjuntos de esta lista.
  • Capa application: funcionalidad que usa la gente.
  • Capa platform: capacidades transversales de las que cuelgan otras.
  • Por defecto: si una institución nueva lo recibe encendido (estrategia opt-out) o no (opt-in).
  • Configurable: si un administrador puede apagarlo desde la interfaz.

Staff — el dashboard administrativo

PQRS y EdFlyer son módulos especializados: se encienden en la institución que los pide. Academy y Soporte no se apagan — son parte de la plataforma.

Portal — familias y estudiantes

Todos cuelgan de portal_base. Apagar la base apaga el portal entero.

Plataforma

Cómo lo ve tu integración

GET /api/client/v1/me devuelve enabledModules con la lista efectiva de la institución. Consúltalo al arrancar en vez de asumir: es la diferencia entre un error claro en tu despliegue y un 403 intermitente en producción.
La navegación del dashboard, la barra del portal y la paleta de comandos (⌘K) filtran contra esta misma lista. Un módulo apagado no es un enlace escondido: es una capacidad que no existe para esa institución.