LTI 1.3, API o xAPI: qué integración conviene en cada caso

LTI 1.3, las API de dominio y xAPI suelen aparecer en la misma comparación, aunque resuelven problemas distintos. LTI 1.3 permite que una plataforma de aprendizaje abra una herramienta externa y le comunique la identidad, el rol y el contexto que autorice la política de privacidad. Una API de dominio expone operaciones de negocio entre sistemas. xAPI define cómo describir y transmitir declaraciones de actividad para que un LRS las conserve y permita consultarlas.

La elección depende primero de la acción que debe realizarse: iniciar una herramienta con una identidad y un contexto verificados, matricular a un estudiante, publicar una calificación, sincronizar un catálogo, registrar interacciones o analizar trayectorias. Después hay que identificar qué sistema inicia cada acción, cuál es la fuente autorizada del dato y cuál puede modificarlo. Una misma arquitectura puede necesitar LTI, una API y xAPI porque cada mecanismo cubre una responsabilidad distinta.

Qué responsabilidad corresponde a cada mecanismo

LTI y una API no son alternativas equivalentes. LTI 1.3 estandariza el lanzamiento seguro de una herramienta externa desde una plataforma de aprendizaje. Utiliza OpenID Connect y JWT, limita el contexto académico que se comparte y ofrece servicios para seleccionar contenidos, consultar participantes o devolver resultados. La plataforma comunica el contexto y los roles; la herramienta aplica su propia autorización.

Una API de dominio expone las operaciones de negocio que deben compartir dos sistemas: crear una matrícula, actualizar un catálogo de cursos, reservar una licencia, consultar un expediente o cancelar una suscripción. Puede ofrecer ese intercambio mediante HTTP y documentarlo con OpenAPI; el significado de cada operación lo acuerdan los responsables del proceso. Por eso una API puede ser la solución adecuada y, a la vez, exigir más gobierno y mantenimiento.

xAPI define declaraciones de actividad que relacionan un actor, un verbo y un objeto, y que pueden incluir resultados, marcas de tiempo y contexto. El emisor envía esas declaraciones a un LRS (Learning Record Store), que las conserva y permite consultarlas. Cada declaración indica qué acción comunicó el emisor, con qué resultado y bajo qué vocabulario. xAPI no resuelve por sí solo el inicio de sesión, la matrícula, la autenticidad de lo ocurrido ni la conversión de una declaración en una calificación oficial.

La combinación es coherente si LTI gestiona el lanzamiento, la API las operaciones de negocio y xAPI describe la actividad que se envía al LRS.

Seis preguntas antes de elegir tecnología

Antes de elegir una tecnología, hay que responder seis preguntas de arquitectura. Si no se aclaran, la discusión sobre estándares oculta un desacuerdo de diseño:

Aclarar quién tiene autoridad sobre el dato resuelve buena parte de la decisión. Si el LMS conserva la calificación oficial, la herramienta externa puede calcular una puntuación, pero debe registrarla mediante el servicio de calificaciones del LMS. Si el CRM gestiona el ciclo comercial de los candidatos, una declaración xAPI no debe modificar el estado de una oportunidad. Si el LRS almacena el histórico de actividad, cada declaración debe tratarse como un registro inmutable, no como una fila de una base de datos operativa.

Los tres mecanismos tienen responsabilidades distintas. El problema aparece cuando se pide a uno de ellos que resuelva a la vez el lanzamiento, las operaciones de negocio y el registro analítico.

Ver a tamaño originalCerrar

Cuándo elegir LTI 1.3

LTI 1.3 encaja cuando una persona abre una herramienta desde una plataforma de aprendizaje y ambas partes ya han establecido una relación de confianza. El mensaje de lanzamiento incluye el identificador del emisor (iss), el despliegue (deployment_id), el identificador opaco del usuario (sub), el curso, los roles normalizados, el recurso de destino y los atributos permitidos por la política de privacidad. LTI Advantage añade servicios acotados: Deep Linking para seleccionar e incrustar recursos, Assignment and Grade Services (AGS) para sincronizar calificaciones y Names and Role Provisioning Services (NRPS) para consultar la lista de participantes.

Ese alcance también marca lo que LTI no resuelve. No debe utilizarse como bus de integración corporativo porque no cubre la sincronización de facturación, contratos, planes formativos ni expedientes académicos completos. Que dos aplicaciones anuncien compatibilidad con LTI 1.3 tampoco garantiza que implementen los mismos servicios ni que la integración soporte una carga elevada. La publicación y actualización de los conjuntos JWKS, el ciclo de vida de los despliegues y la tolerancia a fallos siguen siendo decisiones de ingeniería, como explico en LTI 1.3 en producción: registro, identidad y seguridad entre sistemas.

Estos son los casos principales:

• una actividad o un contenido externos deben abrirse desde el aula virtual sin pedir otras credenciales al estudiante;
• el profesorado necesita explorar un catálogo externo e incrustar enlaces persistentes en el LMS mediante Deep Linking;
• la herramienta externa necesita publicar puntuaciones y comentarios directamente en el libro de calificaciones institucional;
• los privilegios dentro de la herramienta dependen del rol y del contexto comunicados por la plataforma educativa;
• el proveedor busca interoperar con varias plataformas LMS mediante un estándar ampliamente implantado.

LTI resulta insuficiente cuando la integración también necesita operaciones de negocio ajenas a la sesión lectiva. Decir «disponemos de LTI» no explica cómo se tramita el alta de una institución, cómo se facturan las licencias ni cómo se exportan los datos al terminar el servicio.

Cuándo diseñar una API de dominio

Una API de dominio es adecuada cuando dos sistemas necesitan intercambiar entidades y ejecutar operaciones propias del negocio. No es un sustituto improvisado de un estándar: exige acordar operaciones, datos, permisos, versiones y errores.

La API debe organizarse alrededor de entidades y acciones con un responsable funcional claro. «Matricular a un estudiante» expresa mejor la intención que «actualizar usuario». «Reservar plaza» evita que cada cliente calcule la disponibilidad combinando varios atributos. «Cerrar convocatoria» permite comprobar las reglas de negocio, registrar quién ejecutó la acción y enviar las notificaciones necesarias. Una API útil expone el vocabulario del dominio, no la estructura interna de las tablas.

También hay que definir cómo se comporta la API en los procesos asíncronos. La sincronización de un catálogo grande puede aceptar la petición HTTP y comunicar el resultado mediante eventos posteriores. Anular una matrícula requiere idempotencia, trazabilidad y mecanismos de compensación. Si un alta se rechaza por datos incoherentes, la respuesta debe indicar el motivo y permitir que el cliente lo corrija. REST, GraphQL o una cola de mensajería no resuelven por sí solos estas garantías.

Una API de dominio suele ser adecuada cuando:

• se requiere crear, actualizar o cancelar entidades de negocio que no forman parte de las especificaciones de LTI;
• el proceso de integración se ejecuta en segundo plano, sin un usuario navegando interactivamente desde el LMS;
• el consumidor necesita consultar el estado transaccional en tiempo real, más allá de recibir notificaciones de eventos pasados;
• un sistema solicita una operación y necesita saber si se ha aceptado, rechazado o no ha superado la validación;
• el proceso requiere claves de idempotencia o mecanismos de compensación.

El principal coste está en el gobierno y el mantenimiento: hay que versionar los contratos, gestionar permisos, mantener entornos de prueba y retirar de forma ordenada las versiones anteriores. Si cada institución exige parámetros particulares, la API deja de ser una interfaz común y se convierte en un conjunto de excepciones a medida.

Cuándo usar xAPI

xAPI encaja cuando interesa registrar con detalle una interacción o una experiencia de aprendizaje. Cada declaración identifica, como mínimo, un actor, un verbo y un objeto; también puede incluir resultados, contexto y marcas de tiempo. El LRS recibe y conserva la declaración, y las credenciales permiten identificar al emisor. Así puede reunir actividad procedente de simuladores, aplicaciones móviles, laboratorios remotos o el propio LMS sin que todos compartan una base de datos.

La flexibilidad exige gobernar el vocabulario. Si cada proveedor define su propio verbo «completó», sus identificadores de actividad o sus extensiones, las declaraciones pueden cumplir la especificación y, aun así, no ser comparables. Los perfiles de xAPI reducen esa divergencia mediante patrones, vocabularios controlados y plantillas de interacción compartidas.

Un LRS tampoco es, por sí solo, un sistema de gestión académica. Una declaración xAPI deja constancia de lo que un productor autorizado emitió en un momento determinado y es inmutable. Si deja de ser válida, otra declaración la anula mediante un voiding statement; el original se conserva para mantener la trazabilidad. Utilizar esas declaraciones como evidencia académica oficial exige validar el emisor, el perfil xAPI y las políticas de captura.

La inmutabilidad del modelo xAPI no autoriza a conservar datos personales de forma indefinida. La arquitectura debe minimizar los identificadores, fijar periodos de conservación y permitir la exportación, anonimización o supresión física cuando lo exija el RGPD. Por eso un LRS no debe utilizarse como almacén operativo de actas oficiales o matrículas activas.

Los casos principales son:

• se requiere reconstruir la secuencia temporal y las decisiones intermedias de una práctica, no únicamente su calificación final;
• la experiencia formativa se desarrolla fuera del LMS o se distribuye a través de múltiples canales desconectados;
• diversos sistemas deben centralizar evidencias de interacción en un repositorio de analítica común;
• el equipo de investigación o analítica formativa necesita analizar datos con un vocabulario compartido;
• importa conservar la procedencia y la secuencia de los eventos, no mantener el estado actual de una entidad.

Si además se necesita empaquetar contenido, lanzar la actividad y controlar la sesión con un perfil basado en xAPI, conviene evaluar cmi5. Construir esas funciones solo con declaraciones xAPI supone reproducir parcialmente un estándar de lanzamiento.

Tres casos para decidir si conviene combinar mecanismos

Un simulador que se abre desde Moodle y devuelve una nota

LTI 1.3 resuelve el lanzamiento autenticado y comunica los atributos de contexto autorizados por el LMS. La nota se devuelve mediante AGS (Assignment and Grade Services). Si la institución necesita analizar los intentos, las decisiones intermedias y los tiempos de respuesta, el simulador envía esos eventos al LRS mediante xAPI. Una API de dominio puede gestionar las licencias o sincronizar la estructura organizativa sin intervenir en la sesión.

Un catálogo académico que alimenta el CRM y la web pública

Aquí nadie abre una herramienta desde un curso y no se registra una actividad de aprendizaje. Hay que distribuir asignaturas, convocatorias, tarifas y cupos entre sistemas que necesitan conocer el estado actual. Una API de dominio o una arquitectura orientada a eventos, con un responsable claro del catálogo, resuelve esa necesidad. LTI y xAPI no resuelven este intercambio.

Práctica clínica entre aplicación móvil, laboratorio y campus

Las aplicaciones generan declaraciones xAPI sobre la práctica clínica y las envían al LRS. LTI 1.3 interviene cuando el campus virtual abre la actividad o recibe el resultado oficial. La API de dominio gestiona operaciones como asignar turnos, reservar instrumental, verificar acreditaciones o revocar accesos. Los tres mecanismos conviven porque cada uno resuelve una responsabilidad distinta.

La combinación evita duplicidades cuando se define qué hace cada mecanismo, qué sistema controla los datos y cómo se tratan los fallos.

Ver a tamaño originalCerrar

La matriz de decisión

En resumen, LTI inicia la interacción desde el LMS, una API expone operaciones y estados de negocio, y xAPI describe la actividad que se envía a un LRS. Los datos de xAPI solo son comparables si se comparten perfiles, vocabularios e identificadores. Cuando un caso combina varias de estas necesidades, utilizar una sola tecnología puede mezclar responsabilidades y dificultar su evolución.

Cada mecanismo también falla de forma distinta. Si el proceso admite asincronía y el LRS no responde, el productor puede guardar la declaración en una bandeja de salida persistente (outbox), asignarle un identificador estable y reintentar la misma entrega de forma idempotente. También debe registrar la confirmación del LRS y alertar cuando se supere el límite de reintentos. Si el registro condiciona una certificación oficial, la política debe decidir si se bloquea la operación, se degrada el servicio o se deja el resultado pendiente de conciliación. Si la API de matrículas rechaza una petición, debe indicar el motivo para que el sistema llamante decida cómo responder. Si la firma de un lanzamiento LTI no es válida, la sesión no se crea. Estas diferencias muestran por qué los tres mecanismos no deben tratarse como alternativas equivalentes.

En mi trabajo de consultoría EdTech, analizo esta decisión desde cuatro perspectivas: aprendizaje, arquitectura, datos y operación. Comprobar que dos productos declaran compatibilidad no basta para saber si la integración resolverá el caso y podrá mantenerse en producción.