Changelog

POST /org/{slug}/time/attendance/shifts/ crea un turno de Asistencia, fijo o rotativo, con sus descansos y tolerancias, igual que un administrador desde Crehana. Está pensado para sistemas de RR. HH. o de planificación que son dueños de los horarios.

{
  "shift_type": "NON_ROTATING",
  "name": "Mañana 09-18",
  "weekly_schedule": [
    { "day": "MONDAY", "entry_time": "09:00", "exit_time": "18:00" },
    { "day": "TUESDAY", "entry_time": "09:00", "exit_time": "18:00" },

GET /api/v5/rest/org/{organization_slug}/reports/learning/quiz-results/ devuelve los resultados de los quizzes de clase (las evaluaciones de cada video, no la evaluación final del curso, que ya está en reports/learning/quizzes) con una fila por usuario, curso y quiz. Es la misma información del Excel “Resultados de Evaluaciones por Clase” del panel de administración, lista para integrar.

POST /org/{slug}/time/attendance/marks/ registra una marca de asistencia de una persona (entrada, inicio o fin de descanso, salida) con la hora real en que ocurrió. Está pensado para relojes biométricos y sistemas de control de acceso.

{
  "user_id": 97099,
  "mark_type": "ENTRY",
  "marked_at": "2026-10-07T09:00:00-06:00",
  "timezone": "America/Mexico_City"
}

POST /org/{slug}/time/attendance/shift-assignments/ asigna un turno de Asistencia a una o más personas por un período. Está pensado para sistemas de RR. HH. o de planificación que son dueños del horario y lo empujan a Crehana.

{
  "shift_id": "4ed0f6c7-a2a7-4de7-90cd-ae8cf26aabb1",
  "user_ids": [97097, 97099],
  "start_date": "2026-10-13",
  "end_date": "2026-12-31"
}

GET /org/{slug}/timeoff/policies/ acepta el parámetro opcional policy_id para traer una sola política a partir de su id:

GET /org/{slug}/timeoff/policies/?policy_id=1105

La respuesta mantiene el mismo formato paginado, con esa política como único resultado ({"total": 1, "results": [...]}). Si el id no corresponde a una política de la organización, la respuesta es una página vacía ({"total": 0, "results": []}), no un error.

GET /org/{slug}/reports/attendance/shifts/ pide el parámetro obligatorio is_active para elegir qué turnos devolver:

GET /org/{slug}/reports/attendance/shifts/?is_active=true
GET /org/{slug}/reports/attendance/shifts/?is_active=false

true trae solo los turnos activos y false solo los inactivos. El filtro se aplica antes de paginar, así que total, limit y offset cuentan únicamente los turnos de ese estado. Un turno sin estado cargado no aparece en ninguno de los dos.

GET /org/{slug}/reports/talent/competences-results/ deja de incluir configured_semaphore_color en cada fila. El nivel alcanzado sigue llegando en configured_label (Cumple, Sobrepasa, …), junto con configured_scale_result y configured_percentage_result.

GET /org/{slug}/timeoff/requests/ acepta el parámetro opcional email para traer solo las solicitudes de un colaborador a partir de su correo, sin tener que conocer antes su centralized_user_id:

GET /org/{slug}/timeoff/requests/?email=lsanchez@empresa.com

La coincidencia es exacta y no distingue mayúsculas. Si ningún colaborador de la organización tiene ese correo, la respuesta es una página vacía ({"total": 0, "results": []}), no un error.

En GET /org/{slug}/reports/attendance/marks/ y GET /org/{slug}/reports/attendance/daily-management/, from_date y to_date ahora aparecen como obligatorios en la API Reference y en el openapi.json. Ya lo eran: sin alguna de las dos el endpoint responde 400 con This field is required for this report, pero la referencia los listaba como opcionales.

El comportamiento no cambia. Si generás un cliente a partir del openapi.json, al regenerarlo esos dos parámetros pasan a ser obligatorios.

GET /org/{slug}/timeoff/requests/ deja de repetir en cada solicitud la configuración completa de la política y los datos internos del usuario. Cada elemento trae ahora la solicitud (id, start_date, end_date, value, status, comment), quién la pidió en user y a qué política corresponde en policy:

{
  "total": 1,
  "results": [
    {
      "id": "701",
      "start_date": "2026-10-02",

GET /api/v5/rest/org/{organization_slug}/reports/talent/competences-processes/ lista los procesos de evaluación de competencias de la organización, con una fila por proceso: evaluation_id, process_id, process_name, status, created_date, start_date, end_date, updated_date, max_scale y competence_model_id.

Es la puerta de entrada al reporte de resultados: el evaluation_id de cada proceso es el que acepta evaluation_id en /reports/talent/competences-results/, así que primero listás los procesos y después pedís las notas finales del que te interesa.

GET /org/{slug}/timeoff/requests/{request_id}/ devuelve una solicitud de ausencia puntual: quién la pidió, bajo qué política y en qué fechas. Es la pieza que faltaba para los reportes que cruzan usuario, política y solicitud — antes había que traerse el listado completo y buscar ahí adentro.

La solicitud es el mismo objeto que devuelve cada elemento de GET /org/{slug}/timeoff/requests/, así que podés listar y después pedir el detalle sin cambiar de forma: id, start_date, end_date, value, status, comment, created_at, la policy completa (con su policy_type y su quantification) y el user que la generó.

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/

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).

GET /api/v5/rest/org/{organization_slug}/reports/talent/competences-results/ devuelve el resultado de la evaluación de competencias de cada colaborador, con una fila por colaborador y proceso de competencias. Es el mismo dato que el admin ve en Talent una vez aplicada la escala de resultados del proceso, sin tener que descargar el Excel de “Respuestas cuestionarios finalizados”.

En los reportes de asistencia que filtran por colaborador (/reports/attendance/shifts-schedule/, /reports/attendance/marks/ y /reports/attendance/daily-management/), centralized_user_id=0 ahora responde 422. Antes se ignoraba en silencio y devolvía la organización completa con 200, como si no hubieras filtrado. Si tu integración mandaba 0 para decir “sin filtro”, omití el parámetro.

GET /org/{slug}/learning/content/knowledge-hub/catalog/v2/tracks/ devuelve las rutas (tracks) de la organización, paginadas por cursor. Es la pieza que faltaba para armar el flujo completo por API: listar las rutas, elegir una y asignarla con POST .../enrollments/v2/assign-track/ — el id de cada ruta es el track_id que ese endpoint espera.

Cada ruta trae id, name, track_type (TRACK o ACADEMY), is_active, is_hidden, created_at, updated_at, start_date, end_date, version, has_reward, courses_to_complete, courses_to_certificate y total_courses_count. updated_at sirve para detectar qué rutas cambiaron desde tu última sincronización.

GET /api/v5/rest/org/{organization_slug}/reports/learning/performance/ ahora admite limit hasta 500. Antes cortaba en 100 y pedir más devolvía un 422.

Es el mismo techo que ya tenían el reporte general v2 y los cuatro de Asistencia, así que una organización de 500 personas se baja en una sola llamada en vez de cinco.

GET /api/v5/rest/redocs y GET /api/v5/rest/docs ya no dibujan la referencia por su cuenta: ahora redirigen —con un 302— al API Reference de este portal.

Las dos URLs siguen funcionando, así que un enlace guardado no se rompe: te deja en el mismo contenido, con las guías al lado y con el explorador que ya trae el panel de autenticación.

GET /org/{slug}/reports/learning/general-v2/ ya no lista course_enroll_date entre sus parámetros. El filtro por fecha de inscripción se pide con from_date y to_date, igual que en los otros tres reportes de learning.

El reemplazo es from_date solo, sin to_date. Es la parte que se presta a confusión: course_enroll_date no tenía techo —devolvía todo desde esa fecha en adelante— así que poner la misma fecha en los dos extremos del rango no es equivalente, deja un solo día.