Plan Enterprise
Integración Completa
Descripción
Integración completa con APIs REST para sincronización bidireccional. Incluye migración inicial por lotes y sincronización continua automática.
Arquitectura de Integración
¿Cómo funciona el Upsert?
Cuando envías datos a través de nuestros endpoints, el sistema determina automáticamente si debe crear un nuevo registro o actualizar uno existente. Este comportamiento se llama Upsert (Update + Insert).
Flujo de Estudiantes
POST /api/students/push
Se recibe el request y se busca un estudiante con el dni proporcionado.
DNI no existe → Se crea el perfil en la BD + se genera una cuenta Auth. Las credenciales se envían al correo del estudiante.
DNI ya existe → Se actualizan los campos enviados.
Respuesta: 201 (creado) o 200 (actualizado)
Flujo de Empresas
POST /api/companies/push
Se recibe el request y se busca una empresa con el cuit proporcionado.
Cuit no existe → Se crea la empresa con los datos enviados.
Cuit ya existe → Se actualizan los campos enviados.
Respuesta: 201 (creado) o 200 (actualizado)
Requisitos Técnicos
Importante
El área de TI de la universidad debe poder:
- • Enviar peticiones POST para crear y actualizar estudiantes y empresas
- • Manejar autenticación mediante API keys
- • Integrar desde sus sistemas internos
Autenticación y seguridad
Todas las peticiones requieren un token de autenticación enviado en el header:
x-api-key: {api_key}Si una solicitud proviene de una IP no autorizada, la API responderá con un error 403 – Forbidden, incluso si el API Key es válido.
Endpoints Disponibles
Estudiantes
/api/students/pushEnvía los datos de un estudiante para crearlo o actualizarlo. El sistema identifica al estudiante por su dni (documento de identidad). Si el código no existe, se crea un nuevo perfil. Si ya existe, se actualizan los campos proporcionados.
POST /api/students/push{
"status": 201,
"success": true,
"message": "Estudiante creado exitosamente",
"result": "created",
"data": {
"university_id": "UTest"
}
}Referencia de campos
| Campo | Tipo | Requerido | Descripción | Valores permitidos |
|---|---|---|---|---|
| university_id | string | Sí | Identificador de la universidad emisora. Debe estar en la lista de universidades permitidas. Ejemplos: UCSUR, UPC, PUCP. | — |
| cod_student | string | No | Código único de estudiante asignado por la universidad. | — |
| displayName | string | Sí | Nombre completo del estudiante tal como aparece en su documento de identidad. | — |
| string | Sí | Correo electrónico del estudiante. Debe ser único en todo el sistema — no puede estar registrado como estudiante ni como empresa. | — | |
| university | string | Sí | Nombre completo de la universidad a la que pertenece el estudiante. | — |
| career | string | Sí | Nombre de la carrera o programa académico que cursa o cursó el estudiante. | — |
| studentStatus | string | Sí | Estado académico actual del estudiante. | "Estudiante" | "Egresado" |
| phone | string | No | Número de teléfono incluyendo código de país sin el signo +. Ejemplo: 51987654321. | — |
| dni | string | Sí | Documento de identidad. Identificador primario para upsert. Formato varía según país de origen. DNI, CI, CC, NIE, etc. | — |
| cycle | number | No | Ciclo académico actual. Número entero entre 1 y 12. Solo aplica para estudiantes activos. | — |
Nota: El campo dni es el identificador primario para el upsert de estudiantes. Asegúrate de enviar el número de documento de identidad correcto según el país de origen.
Empleadores
/api/companies/pushEnvía los datos de una empresa para crearla o actualizarla. El sistema identifica la empresa por su cuit (número de identificación tributaria). Si no existe, se crea la empresa. Si ya existe, se actualizan los campos proporcionados.
POST /api/companies/push{
"status": 201,
"success": true,
"message": "Compañía creada exitosamente",
"result": "created",
"data": {
"cuit": "20209999980"
}
}Referencia de campos
| Campo | Tipo | Requerido | Descripción | Valores permitidos |
|---|---|---|---|---|
| university_id | string | Sí | Identificador de la universidad que registra la empresa. Debe estar en la lista de permitidas. | — |
| displayName | string | Sí | Nombre comercial de la empresa tal como se mostrará en la plataforma (mín. 2 caracteres). | — |
| cuit | string | Sí | Número de identificación tributaria. RUC en Perú, NIT en Colombia, CUIT/CUIL en Argentina, RUT en Chile, RFC en México. | — |
| string | Sí | Correo electrónico de contacto principal de la empresa. | — | |
| status | string | No | Estado de la empresa en la plataforma. Por defecto "active". | "active" | "inactive" |
| logotype | string | No | URL pública del logo de la empresa. | — |
| description | string | No | Descripción breve de la empresa: actividad, misión o presentación institucional. | — |
| website | string | No | URL del sitio web oficial de la empresa. Debe ser una URL válida (máx. 2083 caracteres). | — |
| representative | string | No | Nombre completo del representante legal o contacto principal de la empresa. | — |
| sector | string | No | Sector o industria al que pertenece la empresa. Ejemplos: Technology, Education, Healthcare. | — |
| phone | string | No | Teléfono con código de país, solo dígitos sin el signo +. Ejemplo: 5112345678. | — |
Nota: El campo cuit es el identificador primario para el upsert de empresas. Asegúrate de enviar el número de identificación tributaria correcto según el país de origen.
Manejo de Errores
La API responde con códigos de estado HTTP claros y mensajes descriptivos ante cualquier error. Es fundamental que las integraciones manejen adecuadamente estos errores, validando los datos enviados y gestionando respuestas como se muestra a continuación.
| Código | Descripción |
|---|---|
| 400 | Datos inválidos |
| 401 | API key inválida |
| 404 | No encontrado |
| 409 | Email duplicado — el correo ya está registrado en otra empresa |
| 429 | Rate limit excedido |
{
"status": 400,
"label": "Bad Request",
"description": "Datos inválidos",
"body": {
"error": "Bad Request",
"message": "El cuerpo de la petición contiene datos inválidos o mal formateados.",
"details": [
{
...
}
]
}
}Rate Limiting
Fases de Implementación
Fase 1: Migración (días 1-3)
Excel inicial + creación masiva en Firebase
Fase 2: APIs (días 4-7)
Configuración de endpoints y autenticación
Fase 3: Go-live (días 8-10)
Capacitación, pruebas y monitoreo
