LTI 1.3, API o xAPI: cómo elegir la frontera correcta

LTI 1.3, una API y xAPI aparecen juntos en muchas conversaciones de arquitectura EdTech. De ahí se pasa con facilidad a una comparativa engañosa: tres columnas, una lista de ventajas y un ganador. El problema es que no compiten por la misma responsabilidad. LTI abre una herramienta con el sujeto, los roles, el contexto del curso, el enlace al recurso y las demás declaraciones que permita la política de datos; una API ejecuta operaciones que pertenecen al dominio de dos sistemas; xAPI conserva declaraciones sobre una actividad para que puedan consultarse y analizarse.

Para decidir empiezo por los verbos: ¿hay que abrir, matricular, calificar, sincronizar, registrar o analizar? Después dibujo quién inicia cada acción, quién es dueño del dato y qué sistema puede corregirlo; solo entonces elijo el mecanismo. Una misma solución puede necesitar LTI, una API y xAPI sin que eso sea redundante, porque cada uno protege una frontera distinta.

La comparación empieza mal cuando busca un ganador

Decir que LTI es mejor que una API resulta tan poco útil como decir que un torno es mejor que un calibre. LTI 1.3 es un estándar de interoperabilidad entre una plataforma de aprendizaje y una herramienta. Define mensajes de lanzamiento seguros, información académica acotada y funciones como selección de contenidos, consulta de participantes o devolución de resultados. Su pregunta principal es: «¿Cómo entra una persona desde esta plataforma en esta herramienta y qué puede hacer después?».

Una API de dominio responde a otra pregunta: «¿Qué operaciones necesitan compartir estos dos sistemas?». Puede crear una matrícula, actualizar un catálogo, reservar una licencia, consultar un expediente o cerrar una cuenta. La semántica no viene dada por el transporte HTTP ni por OpenAPI; la acuerdan los propietarios del proceso. Por eso una API puede ser exactamente la decisión correcta y, al mismo tiempo, la opción con más coste de gobierno.

xAPI describe la actividad mediante declaraciones que relacionan actor, verbo y objeto, con resultado y otros datos cuando proceda. Esas declaraciones se envían a un LRS, un almacén especializado en conservar y consultar registros de actividad de aprendizaje. La pregunta es: «¿Qué ha declarado el productor, con qué resultado y bajo qué vocabulario común?». xAPI no establece por sí solo cómo abrir la aplicación, matricular a la persona, demostrar que el hecho declarado ocurrió ni convertir una declaración en la nota oficial de una asignatura.

Combinar LTI, una API y xAPI tiene sentido cuando cada mecanismo conserva una responsabilidad y una autoridad distintas.

Seis preguntas antes de elegir tecnología

Antes de revisar especificaciones, fijaría seis decisiones. Si no están claras, la discusión sobre estándares solo oculta un desacuerdo de arquitectura.

La pregunta de autoridad suele resolver más que las otras cinco. Si el LMS conserva la calificación oficial, la herramienta puede calcular un resultado, pero la operación que lo publica debe respetar el contrato de calificaciones del LMS. Si el CRM es dueño de las oportunidades comerciales, una declaración xAPI no debería convertirse en una orden encubierta para cambiar su estado. Si el LRS conserva el registro de actividad, no conviene tratar cada declaración como una fila mutable de una base de datos operativa.

Abrir la imagen a tamaño completo

Cuándo elegir LTI 1.3

Elegiría LTI cuando el recorrido nace en una plataforma de aprendizaje y la herramienta necesita recibir a la persona con un acuerdo de confianza ya establecido. El lanzamiento aporta el emisor, el despliegue, el sujeto, el curso, los roles y el recurso, según el mensaje y la política de datos. LTI Advantage añade funciones acotadas: Deep Linking para que el docente seleccione recursos; AGS para las calificaciones; NRPS para consultar miembros y roles del curso.

Esa cobertura tiene límites útiles: LTI no debería convertirse en el bus general de la institución, pues no define cómo sincronizar facturas, licencias, centros, contratos o expedientes completos. Tampoco garantiza que dos productos que anuncian «LTI 1.3» implementen las mismas opciones ni que la integración sea operable. El registro, la privacidad, las claves y los fallos siguen siendo decisiones de arquitectura, que desarrollo en LTI 1.3 en producción.

LTI encaja especialmente bien en estas situaciones:

• una actividad externa debe abrirse desde el curso sin otra contraseña;
• el docente necesita elegir contenido y dejar un enlace estable en el LMS;
• la herramienta devuelve una puntuación al libro de calificaciones;
• los permisos dependen del curso y del rol comunicado por la plataforma;
• el proveedor debe poder instalarse en varias plataformas mediante un contrato conocido.

No lo elegiría como único mecanismo si la integración necesita operaciones propias que el estándar no contempla. «Tenemos LTI» no responde cómo se da de alta una institución, cómo se facturan licencias o cómo se exportan todos los datos al terminar el contrato.

Cuándo diseñar una API de dominio

Una API es la frontera adecuada cuando dos productos necesitan compartir operaciones propias de su negocio. No es el recurso de emergencia que queda cuando no existe un estándar; a veces es el contrato central y debe recibir más cuidado que cualquier integración auxiliar.

La diseñaría alrededor de acciones y recursos que tengan un propietario claro. «Crear matrícula» expresa más que «actualizar usuario». «Reservar licencia» evita que cada consumidor deduzca disponibilidad a partir de tres campos. «Cerrar convocatoria» permite aplicar reglas, registrar quién lo decidió y emitir los efectos posteriores. Una API útil expone el lenguaje del proceso, no las tablas internas de la aplicación.

También exige decidir qué ocurre fuera de la respuesta inmediata. Una sincronización de catálogo puede aceptar el trabajo y publicar después su resultado. Una baja puede necesitar idempotencia, auditoría y compensación. Un alta bloqueada por datos incompletos debe devolver un error que el sistema llamante pueda resolver. Ninguna de estas decisiones aparece por usar REST, GraphQL o una cola.

Recurriría a una API cuando:

• hay que crear o modificar una entidad de negocio que no forma parte de LTI;
• el proceso se inicia sin una persona navegando desde el LMS;
• el consumidor necesita consultar el estado actual, no solo saber que algo ocurrió;
• existe una orden cuya aceptación o rechazo debe quedar clara;
• el contrato necesita transacciones, idempotencia o una reversión definida.

El coste procede de la responsabilidad compartida: hay que versionar el contrato, gobernar los permisos, mantener entornos de prueba y acordar la retirada. Si cada cliente recibe una variante, la API deja de ser un producto común y pasa a ocultar integraciones a medida detrás del mismo dominio.

Cuándo usar xAPI

xAPI encaja cuando la unidad que interesa es una actividad declarada. El productor aporta como mínimo un actor, un verbo y un objeto, y puede añadir el resultado, el contexto y el instante. El LRS conserva la declaración y gestiona la autoridad de acuerdo con las credenciales autenticadas y con las reglas de recepción de xAPI. Así, el modelo puede reunir registros procedentes de un simulador, una aplicación móvil, un laboratorio, un recurso web o el propio LMS sin obligar a que todos compartan el mismo esquema interno.

La flexibilidad tiene una condición: el vocabulario se gobierna. Si cada proveedor inventa su verbo «completó», su identificador de actividad y su estructura de extensiones, todos producen xAPI válido y nadie puede comparar nada. Los perfiles existen para acotar ese espacio: fijan conceptos, patrones y plantillas que una comunidad puede compartir.

xAPI tampoco es un expediente académico por defecto. Una declaración deja constancia de lo que un productor autorizado afirmó y se espera que sea permanente; cuando deja de ser válida se anula mediante otra declaración, no se edita como una fila cualquiera. La anulación corrige su validez semántica, pero no borra la declaración. Que sirva además como evidencia educativa exige validar quién la produjo, cómo se autenticó, qué perfil y vocabulario aplicó y qué reglas de captura y procedencia se cumplieron.

La permanencia describe el ciclo de vida de xAPI; no autoriza a conservar datos personales sin límite. La arquitectura debe minimizar identificadores, fijar plazos de conservación y permitir la exportación, la anonimización o la supresión física cuando proceda conforme a la finalidad y la base jurídica aplicables. Este límite complica cualquier diseño que pretenda usar el LRS como base operativa de matrículas o calificaciones oficiales.

Lo usaría cuando:

• importa reconstruir la secuencia de una práctica, no solo su resultado final;
• la actividad ocurre fuera del LMS o atraviesa varios canales;
• varios productores deben enviar registros de actividad a un almacén común;
• análisis y evaluación necesitan un vocabulario acordado;
• conservar la procedencia del evento resulta más importante que mantener un estado mutable.

Si además hacen falta empaquetado, lanzamiento y reglas de sesión para contenidos basados en xAPI, revisaría cmi5. Intentar construir esas responsabilidades solo con declaraciones xAPI reproduce un estándar de lanzamiento de forma incompleta.

Tres casos que obligan a combinar mecanismos

Un simulador que se abre desde Moodle y devuelve una nota

LTI 1.3 se ocupa del lanzamiento y de las declaraciones académicas que la plataforma haya autorizado, mientras que la devolución de la calificación encaja en AGS. Si el producto necesita estudiar los intentos, las decisiones y las rutas dentro del simulador, xAPI puede conservar esos registros en un LRS. Una API propia puede seguir siendo necesaria para contratar licencias o administrar la institución, pero no para sustituir el lanzamiento.

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

En este caso no hay una persona que abra una herramienta desde un curso ni se está registrando una experiencia de aprendizaje. La necesidad consiste en distribuir asignaturas, convocatorias, precios y estados entre sistemas que deben conocer el valor actual. Usaría una API o eventos de dominio, con un propietario inequívoco del catálogo, porque añadir LTI o xAPI solo cambiaría los nombres del acoplamiento.

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

xAPI puede conservar los registros de práctica con un perfil común y llevarlos al LRS, mientras que LTI sigue siendo útil cuando el campus abre una actividad o necesita recibir el resultado oficial. La API resuelve las órdenes de negocio, como asignar una práctica, reservar un equipo, obtener el estado de una acreditación o retirar el acceso. Las tres fronteras coexisten porque el proceso contiene tres responsabilidades.

Abrir la imagen a tamaño completo

La matriz de decisión

Mi recomendación final cabe en tres reglas: usar LTI cuando la relación empieza en el LMS y necesita un lanzamiento bajo confianza establecida; diseñar una API cuando un sistema pide a otro una operación de negocio o su estado actual, y recurrir a xAPI cuando se quieren conservar registros de actividad. Esos registros solo serán comparables entre proveedores si comparten perfiles, vocabularios e identificadores y se validan al recibirlos. Si una necesidad contiene dos de esos verbos, probablemente requiera dos fronteras.

La arquitectura se vuelve más sencilla cuando cada mecanismo puede fallar sin fingir que ha fallado otro. Si el caso tolera asincronía y el LRS no responde, la actividad solo continúa con una bandeja de salida duradera: el productor asigna un identificador estable antes del primer envío, conserva la declaración, reintenta de forma idempotente, registra la confirmación del LRS y alerta al superar los límites acordados. Cuando el registro condiciona una nota o una certificación, la política decide de antemano si se bloquea la operación, se degrada el servicio o se deja el resultado pendiente. Si la API rechaza una matrícula, el proceso debe detenerse y explicar qué dato falta. Si la firma del lanzamiento LTI no se valida, no se crea sesión. Esa diferencia operativa confirma que nunca fueron tres alternativas equivalentes.

Última revisión: 27 de julio de 2026.

Alberto Lara Hernández trabaja en dirección técnica, arquitectura de plataformas de aprendizaje e IA aplicada con gobierno. Publica análisis para equipos que necesitan tomar decisiones tecnológicas que sigan siendo explicables cuando el sistema crece.