> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://developer.crehana.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://developer.crehana.com/_mcp/server.

## `course_enroll_date` deja de estar documentado en el reporte general v2

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

| Antes                            | Ahora                                      |
| -------------------------------- | ------------------------------------------ |
| `?course_enroll_date=2026-01-01` | `?from_date=2026-01-01`                    |
| no se podía cerrar el rango      | `?from_date=2026-01-01&to_date=2026-03-31` |

Los resultados pueden diferir en el borde del rango: `from_date` y `to_date` se
interpretan en la zona horaria de la organización —la misma en la que el reporte
devuelve la fecha de inscripción— mientras que `course_enroll_date` comparaba en
UTC. Si una inscripción cae en las horas de diferencia entre las dos zonas,
antes podía quedar fuera del filtro y ahora entra, o al revés.

> **Note**
>
> El parámetro se sigue aceptando por compatibilidad, así que una integración que
> todavía lo mande no se rompe y no hace falta migrar de urgencia. Dejó de estar
> documentado porque va a desaparecer: al pasar a `from_date` te quedás con el
> mismo filtro, además del extremo superior del rango.

El campo `course_enroll_date` de la respuesta no cambia: sigue siendo la fecha
de inscripción de cada matrícula. Lo que se retira es el parámetro de consulta
homónimo.

## Los endpoints deprecados salen del portal

Ocho endpoints que ya estaban marcados como deprecados dejan de aparecer en esta
documentación. **Siguen respondiendo con normalidad**: si tu integración los usa,
no se rompe nada y no hay que hacer nada con urgencia.

Lo que cambia es que dejamos de ofrecerlos a quien recién empieza, para que nadie
construya sobre un camino que ya está marcado para salir.

Cada uno tiene su reemplazo:

| En lugar de                                               | Usá                                                  |
| --------------------------------------------------------- | ---------------------------------------------------- |
| `GET /org/{slug}/areas`                                   | `GET /org/{slug}/organizations/areas/`               |
| `GET /org/{slug}/headquarters`                            | `GET /org/{slug}/organizations/headquarters/`        |
| `GET /org/{slug}/positions`                               | `GET /org/{slug}/organizations/positions/`           |
| `GET /org/{slug}/position_categories`                     | `GET /org/{slug}/organizations/position-categories/` |
| `POST /org/{slug}/organizations/custom-fields/`           | `POST /org/{slug}/custom-fields/`                    |
| `PUT /org/{slug}/organizations/users/{id}/custom-fields/` | `POST /org/{slug}/users/{id}/custom-fields/`         |
| `PUT /org/{slug}/users/{id}/`                             | `POST /org/{slug}/users/update_user/`                |
| `GET /org/{slug}/permission_groups`                       | —                                                    |

El listado de grupos de permisos no tiene sucesor: se retira sin reemplazo.

Los reemplazos no son sólo un cambio de ruta: devuelven la misma envoltura que el
resto de la API y aceptan paginación donde corresponde, así que conviene migrar
aunque el viejo siga funcionando.

`GET /org/{slug}/users/` se queda documentado aunque esté deprecado, porque es el
listado que más se usa y su reemplazo todavía no cubre todos los casos.