Por qué el SIS debe ser la fuente de verdad
Cuando la plataforma de fotos mantiene su propia nómina, en seis meses está desactualizada: estudiantes nuevos no aparecen, retirados siguen activos y los apoderados reciben emails equivocados. Integrar con el SIS evita ese problema desde el día uno.
Mecanismos de integración
API REST con autenticación por token, webhooks para eventos (alta, baja, cambio de curso) y CSV programado para colegios sin API. Los tres conviven; el colegio elige según su madurez técnica.
Qué devuelve la plataforma al SIS
Thumbnails y fotos carnet por ID de estudiante, listas para mostrar en el SIS, el LMS, el directorio interno o el sistema de control de acceso. Sin renombrado manual de archivos.
Errores frecuentes a evitar
Sincronizar por nombre en vez de por ID (los homónimos rompen el match), olvidar el campo de jornada en colegios con doble jornada, y dejar el CSV sin versionar (cuando algo se rompe, no hay manera de reconstruir).
Qué preguntar al proveedor
¿Cuál es el SLA del webhook? ¿Cómo manejan reintentos en caso de error? ¿Quién es responsable cuando el SIS cambia el esquema? ¿El thumbnail devuelto cumple las especificaciones de carnet del colegio?
Preguntas frecuentes
- ¿Qué datos del SIS se sincronizan?
- Roster de estudiantes, cursos, jornada, apoderados y emails. La sincronización es unidireccional desde el SIS (fuente de verdad) hacia la plataforma de fotografía; el SIS recibe de vuelta thumbnails y fotos carnet por ID.
- ¿Sirve si el colegio usa un SIS propio?
- Sí. Una buena plataforma se integra por API REST, webhooks o CSV programado. Lo importante es que el SIS sea fuente de verdad y la plataforma no cree una nómina paralela.
- ¿Qué pasa cuando un estudiante cambia de curso a mitad de año?
- El cambio se refleja en la próxima sincronización; las fotos quedan asociadas al estudiante (ID), no al curso, así que el historial se mantiene aunque cambie la sala.