Changelog

Sesiones en vivo: listar, crear, invitar y marcar asistencia

Nueva sección Live Sessions con los cuatro endpoints del ciclo completo de una sesión en vivo, para que una integración haga por API lo que hoy solo se puede hacer desde el panel de administración.

GET  /org/{slug}/learning/live-sessions/
POST /org/{slug}/learning/live-sessions/
POST /org/{slug}/learning/live-sessions/{live_session_id}/participants/
POST /org/{slug}/learning/live-sessions/{live_session_id}/attendance/

Listar las sesiones

GET .../live-sessions/ devuelve las sesiones de la organización, de la más reciente a la más antigua. status elige el tramo: NEXT (por defecto) las que todavía no terminaron y PAST las que ya terminaron — para recorrer todo el calendario hay que pedir los dos. La paginación es por página: first (de 1 a 100, por defecto 10) y page (desde 1). ids acota el listado a las sesiones que le pases.

Los contadores miran todo el calendario, no la página: total son todas las sesiones de la organización, y next_sessions_count y past_sessions_count dicen cuántas hay en cada tramo. results trae solo la página pedida del status pedido.

{
  "total": 3,
  "next_sessions_count": 2,
  "past_sessions_count": 1,
  "results": [
    {
      "id": "1258",
      "session_title": "Onboarding comercial",
      "instructor_name": "Katherine N.",
      "type_session": "ONLINE",
      "location": "https://meet.google.com/abc-defg-hij",
      "time_zone": "TIME_ZONE_ES_PE",
      "start_date": "2026-10-01T10:00:00",
      "end_date": "2026-10-01T11:00:00",
      "start_date_utc": "2026-10-01T15:00:00+00:00",
      "end_date_utc": "2026-10-01T16:00:00+00:00",
      "timeline": "FUTURE",
      "total_guests": 2,
      "has_qr_available": true,
      "issues_certificate": false
    }
  ]
}

Cada sesión trae las fechas dos veces: start_date y end_date son la hora de reloj en la zona horaria de la sesión (time_zone) y van sin marca de zona, y start_date_utc / end_date_utc son el mismo instante en UTC. Usá el par UTC para ordenar o comparar sesiones de zonas distintas.

En la respuesta del POST de creación el par UTC viene en null: el servicio devuelve ahí la misma hora de reloj que le mandaste, sin convertir. Leé la sesión con el GET para obtener los instantes en UTC.

Crear una sesión

POST .../live-sessions/ crea la sesión y responde 201 con la sesión creada. Obligatorios: session_title, description, start_date, end_date, time_zone y type_session (ONLINE o PRESENCE). Opcionales: instructor_name, location (el link de la reunión si es ONLINE, la dirección si es PRESENCE), cover_file_id, resource_file_ids, participant_user_ids, has_qr_available e issues_certificate.

Las fechas son hora de reloj en time_zone y van sin offset (2026-10-01T10:00:00). Mandar un offset responde 422: el offset se descartaría y la sesión quedaría a otra hora que la pedida. end_date tiene que ser posterior a start_date.

Si la organización ya tiene una sesión con ese título, el título se guarda con un sufijo numérico — por eso conviene leer el session_title de la respuesta en vez de asumir el que mandaste.

Invitar participantes

POST .../live-sessions/{id}/participants/ invita usuarios a la sesión. Los user_ids son los ids de usuario de learning, los que devuelve GET /org/{slug}/learning/users/ en user.id. Con send_notification: true se manda el correo de invitación, si la organización tiene esa notificación activa.

La asignación se procesa en segundo plano: la respuesta es 202 y confirma qué se aceptó, no qué ya está aplicado. Los usuarios que no pertenecen a la organización vuelven en invalid_user_ids y no se asignan; si ninguno de los pedidos pertenece, la respuesta es 422.

{
  "message": "Assignment of 2 users in live session 1258 queued",
  "code": "LIVE_SESSION_PARTICIPANTS_QUEUED",
  "datetime": "2026-09-16T10:30:00.000Z",
  "data": {
    "live_session_id": 1258,
    "engagement_id": "907",
    "state": "SUBMITTED",
    "total_users_requested": 3,
    "total_users_accepted": 2,
    "total_users_skipped": 1,
    "invalid_user_ids": [605999],
    "errors": []
  }
}

Marcar asistencia

POST .../live-sessions/{id}/attendance/ registra la asistencia. Mandá user_ids con los usuarios a marcar, o all_participants: true para marcar a todos los participantes de la sesión — uno u otro, no los dos: mandar ambos responde 422, igual que no mandar ninguno.

También se procesa en segundo plano (202). errors explica cada usuario que quedó afuera: ya estaba registrado, no se encontró en la organización, o está inactivo. Si no se pudo registrar a nadie, la respuesta es 422 con esos mismos motivos.

Una sola organización

Los cuatro endpoints trabajan sobre la organización de la api-key: pedir el slug de otra organización responde 403, no datos. Un 401 significa que las credenciales no llegaron o no son válidas, y un 400 que el pedido tiene un problema de validación — así el motivo del rechazo se distingue sin leer el detalle.

Listar las politicas de tiempo libre de la organizacion

GET /org/{slug}/timeoff/policies/ devuelve el catálogo de políticas de ausencia configuradas por la organización: vacaciones, licencias y permisos. Es la configuración de cada política, no las solicitudes ni los datos de los colaboradores — para eso sigue estando GET /org/{slug}/timeoff/requests/.

Cada política trae id, name, description, policy_type (la categoría, con su id y su name), is_paid, is_unlimited, quantification (DAYS u HOURS), needs_approvals y status (enabled o disabled).

{
  "total": 335,
  "results": [
    {
      "id": "1107",
      "name": "Vacaciones México",
      "description": "15 días por año",
      "policy_type": { "id": 15, "name": "Vacaciones" },
      "is_paid": true,
      "is_unlimited": true,
      "quantification": "DAYS",
      "needs_approvals": false,
      "status": "enabled"
    }
  ]
}

El id de cada política es el mismo que devuelve policy_id en el listado de solicitudes, así que podés cruzar ambos recursos sin repetir la configuración en cada fila.

La paginación es la misma del resto de la sección: limit (de 1 a 50) y offset. Filtros opcionales: search (por nombre, sin distinguir mayúsculas), name (nombre exacto), policy_type_ids (repetible) e is_paid. Un order_by desconocido responde 422.

Sólo se listan políticas de la organización de la api-key: pedir el slug de otra organización responde 403, no datos.