Cómo funciona Omniscol — una sola API, una única fuente de verdad

Conviene conocer algunos aspectos sobre cómo está construido Omniscol antes de integrarlo: explican por qué la API es tan completa, cómo la interfaz se adapta a cada usuario, y un punto de confidencialidad que conviene tener presente.

Una sola aplicación sobre una sola API

Omniscol se ejecuta como una única aplicación web en su navegador. Cada pantalla, botón y tabla se dibuja llamando a la API pública de Omniscol —la misma API que usted puede llamar—, documentada en la referencia de API interactiva de Omniscol, la página Desarrolladores (omniscol.com/es/developers). No hay una API oculta, «real», detrás de la que usted integra: lo que la interfaz usa es lo que usted obtiene. Algunas operaciones van en sentido contrario —ofrecidas para la integración pero no utilizadas por la propia aplicación—: por ejemplo, los puntos de acceso de búsqueda avanzada y resolución de entidad (pensados para un agente de IA a través de MCP), o los que permiten a un sistema externo alimentar Omniscol (un ETL que mantiene sincronizada una base de datos externa).

operationId — una clave, una única fuente de verdad

Cada operación es un par método + URL (por ejemplo GET /api/schedules/lessons/{datesrange}), y cada una lleva un identificador estable: su operationId (aquí os_schedules_dates_get). El nombre está estructurado: os (Omniscol), luego el módulo (schedules), luego aquello sobre lo que actúa la operación (dates —a veces varios segmentos unidos por guiones—) y siempre el método HTTP al final (get, post, put, delete). Esa clave única es la que Omniscol usa en todas partes: para nombrar la operación en la página Desarrolladores, para construir la herramienta MCP correspondiente y para designarla desde una personalización de API o desde esta ayuda. Definida una sola vez, mantiene todas las superficies sincronizadas: la documentación, las herramientas y la interfaz no pueden divergir, porque todas leen la misma definición.

La interfaz sigue sus permisos

Un elemento gráfico con una acción —un botón, una pestaña, una entrada de menú— solo aparece cuando la operación que lo sustenta le es accesible. Esto depende de su rol y de sus roles personalizados (véase Usuarios y roles), de su plan y de sus opciones (véase Planes y opciones de Omniscol). Cambie uno de estos elementos y la interfaz se recompone: elementos, e incluso módulos enteros, aparecen o desaparecen en consecuencia.

El mismo principio actúa más allá de sus permisos personales. El departamento de informática puede desactivar ciertas operaciones mediante una personalización de API, y los elementos correspondientes desaparecen de la interfaz (véase Personalización de API). Lo mismo ocurre cuando un dato se mantiene actualizado mediante una sincronización externa: su creación y su modificación locales pueden desactivarse, y sus controles ceden entonces el paso a la sincronización (véase Sincronización con sistemas externos).

Por eso Omniscol no tiene ningún portal separado para alumnos o profesores. Hay una sola aplicación; cada persona ve la interfaz sincronizada con sus propios permisos: un alumno, un profesor, un administrador y el titular de un rol personalizado obtienen exactamente las operaciones a las que tienen derecho, y nada más.

La interfaz es una comodidad, no el cerrojo

Como la interfaz está guiada por sus permisos, se podría tender a ver un botón oculto como una frontera de seguridad. No lo es. Cada llamada se vuelve a verificar en el servidor frente a su identidad y sus permisos; una operación a la que no tiene derecho se rechaza allí, muestre lo que muestre la interfaz. La interfaz se adapta por claridad y comodidad; la frontera real se aplica en el servidor, en cada solicitud.

Tokens y enlaces de compartición, el mismo modelo

Un token de API o un enlace de compartición está restringido a un conjunto de operaciones: las que usted autoriza al crearlo. El servidor aplica esa restricción en cada llamada, exactamente igual que para un usuario conectado. Un enlace de compartición, un token y una persona en la interfaz son tres formas de alcanzar la misma API controlada por permisos, nunca una puerta trasera que la eluda.

Superar un corte de conexión

Como cada pantalla lee la API, Omniscol también puede conservar en su navegador las respuestas ya recibidas, para que una breve pérdida de red no interrumpa su lectura. Esta copia local vive en su base de datos (IndexedDB), junto al caché de páginas habitual del navegador. Es un caché de lectura: si la conexión se cae, sigue viendo lo que ya había abierto. No pone sus modificaciones en cola ni las reproduce: una modificación siempre pasa por el servidor.

Esta copia local se basa en su consentimiento. La primera vez en un navegador, Omniscol le pregunta si confía en él; la copia comienza una vez que ha aceptado. La entrada Caché sin conexión del menú de usuario la activa o la borra después en cualquier momento: una marca de verificación indica que está activa.

Dos cosas que conviene saber:

• Los datos personales quedan excluidos. Solo se conservan las lecturas correctas; las respuestas que el servidor marca como no almacenables (datos de sesión y de autenticación) nunca se guardan en caché, y de lo que sí se almacena el software retira los datos de contacto de las personas —correo electrónico, teléfono, fecha de nacimiento, login, número de identificación, estado de la contraseña— y elimina por completo las cuentas de administrador. La copia local contiene los datos de trabajo habituales, no el directorio nominal.
• En un equipo compartido, prefiera una ventana de navegación privada (incógnito). Cerrar sesión no borra esta copia local (ni el caché normal del navegador); una ventana privada descarta ambos al cerrarse. Es el cuidado que merece cualquier aplicación web en una máquina que no controla.