Skip to main content
Esta sección es un mapa interno, no un contrato. Documenta lo que existe para que el equipo pueda orientarse: qué hay montado, dónde vive el código y bajo qué middleware corre.
Nada de lo que hay aquí es una API pública. Estos endpoints cambian con el producto, no están versionados y no tienen esquema declarado. Para integrar un sistema externo existe el Client API, y solo ese.

Las cuatro capas

Dashboard

612 endpoints en 55 grupos bajo /api/v1. Sesión de Better Auth, tenant por subdominio, acceso validado. Es el grueso del producto.

Portal

17 endpoints bajo /api/v1/portal. Familias y estudiantes, detrás de portalMiddleware, con el acceso colgado de la cuenta financiera.

Pública

40 endpoints bajo /api/public. Sin sesión: widget, formularios, PQRS, firmas, callbacks de OAuth y webhooks entrantes.

Interna

25 endpoints bajo /api/internal. Solo para tareas de Trigger.dev, con secreto compartido.
A eso se suman las 41 operaciones del Client API (documentadas en la pestaña Referencia) y siete rutas sueltas de arranque: /api/health, /api/onboarding/*, /api/session/tenants y /api/access-requests.

Dónde está el peso

Los diez grupos más grandes del dashboard dicen bastante sobre en qué consiste el producto:

Cómo se construyen estos catálogos

No están escritos a mano. scripts/generar-docs-mintlify.mjs lee apps/web/src/server/app.ts, resuelve qué archivo está montado en cada prefijo y extrae los métodos declarados en ese archivo. Cada página dice contra qué commit se generó.
La extracción es estática. Reconoce las dos formas que usa el repo — el xRoute.get('/ruta', ...) de Hono y el createRoute({ method, path }) de zod-openapi — y exige que la ruta empiece por / para no confundir un c.get('tenant') con un endpoint. Una ruta montada de una forma distinta no aparecería: el número es un piso confiable, no una prueba de exhaustividad.
La forma de verificarlo es correr el generador después de tocar rutas y mirar el diff. Si cambió el conteo, cambió la superficie.