Airtable
Airtable es la "fuente de verdad" del negocio: quién es alumno, qué tiene contratado, en qué estado está y con qué fechas. El Campus refleja lo que hay en Airtable, no al revés. Esta página reúne todo lo relacionado con Airtable en un solo sitio: cómo se conecta con el Campus, para qué se usa y qué hacer cuando algo no aparece.
La regla de oro
Si un alumno "no existe" en el Campus, o algo suyo no cuadra, lo primero es mirar Airtable. El Campus no inventa datos: los toma de ahí.
Cómo se conecta el Campus con Airtable
Mucha gente supone que Airtable "avisa" al Campus con una automatización. No es así. Es justo al revés: el Campus va a leer Airtable él solo, cada pocos minutos, y se trae lo que haya cambiado.
Cómo llega Airtable al Campus
- Se marca la filaEn la ficha de Ventas, administración marca la casilla "Campus". Eso dice: esta persona va al Campus.
- El Campus lee soloCada 10 minutos, a cualquier hora, el Campus va a Airtable (España y Latinoamérica) y se trae las filas marcadas que hayan cambiado.
- Se actualiza el CampusCrea o actualiza la matrícula del alumno con su estado y sus fechas. No hace falta ninguna automatización de Airtable.
El disparador, por tanto, no es una automatización de Airtable (de hecho están todas ocupadas), sino marcar la casilla "Campus" en la fila de Ventas. Una vez marcada:
- El Campus la recoge en la siguiente lectura (como mucho, 10 minutos).
- Si la fila cambia después (estado, fechas…), el Campus vuelve a recogerla y se actualiza.
- Si no está marcada, el Campus no la ve — por muy completa que esté.
Detalle técnico (para el equipo de desarrollo)
El Campus lee Airtable de dos maneras, ambas por la API de Airtable (no por automatizaciones de Airtable):
- Sincronización periódica (el camino en vivo). Una tarea programada (
cron) en Vercel,/api/cron/airtable-sync, corre según*/10 * * * *(cada 10 min, las 24 horas: el embudo de Latinoamérica vende de madrugada). Lee la tabla Ventas de las dos bases —España y Latinoamérica—, cada una con su propio cursor (airtable_sync_cursors); por cada fila marcada conis_campusejecuta la ingesta de matrículas (idempotente) y archiva feedbacks desde el mismo snapshot. Si la lectura de una base falla, la otra sigue y avanza; la que falló conserva su cursor y la corrida queda marcada en rojo en Vercel para que se vea. - Lectura en vivo de la ficha (
read-sale.ts), bajo demanda cuando el equipo abre la ficha del alumno (ver abajo). No persiste nada.
Existe además un webhook receptor (/api/webhooks/airtable), con la misma ingesta que el cron y protegido por firma. Es el camino previsto para el alta al instante (que Make lo llame en el momento de la compra, sin esperar a la siguiente lectura); todavía no está conectado desde Make, así que hoy el camino vivo sigue siendo el cron.
Para qué usa el Campus Airtable
Airtable aparece en tres sitios del Campus. El acceso cambia entre ellos, así que cada uno dice para quién es:
Para qué usa el Campus Airtable
Alta y matrículasCrea la cuenta del alumno y le matricula en lo que tiene contratado. Su estado y sus fechas también salen de aquí.👁️ Automático
Ficha en el chatCuando el tutor abre la ficha de un alumno, el Campus lee de Ventas sus datos al momento: nombre, nivel, programa y los comentarios de la llamada de alta.👁️ Solo el equipo
Archivo de feedbacksEn la misma lectura, los feedbacks marcados como cerrados en Airtable se archivan solos en el Campus.👁️ Automático
- Alta y matrículas → es lo que explica Acceso y tutoría: el estado y las fechas de la ficha de Airtable son los que mandan sobre lo que un alumno puede hacer.
- Ficha en el chat → cuando el tutor abre la ficha de un alumno desde el chat de soporte, ve sus datos de Ventas leídos al momento (nombre, nivel, programa y los comentarios de la llamada de alta). Es información privada del equipo: el alumno nunca la ve.
- La casilla de la semana (S1–S13) → cuando la tutora responde una semana, el Campus marca solo la casilla S-N de la fila de Ventas (en la base de España o de Latinoamérica, según el alumno). Es el único dato que el Campus escribe en Airtable. La tutora y el gestor ven bajo cada respuesta si se marcó, y pueden reintentar si falló. → Ver La casilla de la semana en Airtable. (El camino contrario —archivar en el Campus los feedbacks marcados como cerrados en Airtable— todavía no está conectado.)
El acceso a Airtable: token y seguridad
Para leer Airtable, el Campus usa un token de acceso personal (Personal Access Token) de Airtable. Conviene saber dónde está y dónde no:
- No es una "app conectada" ni una integración de las que salen en el panel de la base. Es un token creado en el Builder Hub de Airtable (
airtable.com/create/tokens); por eso no aparece listado como aplicación en la base. - No está en el código. Vive solo como variable de entorno en Vercel (
AIRTABLE_API_KEY). Nunca se sube al repositorio. - Permisos mínimos: el token está acotado a esa base y, en la ficha del chat, el Campus pide únicamente los campos que necesita (nada financiero).
- La tarea programada se protege aparte con su propio secreto (
CRON_SECRET), para que nadie de fuera pueda dispararla.
Si hay que rotar el token
Si el token de Airtable se cambia o caduca, hay que actualizar AIRTABLE_API_KEY en Vercel. Mientras esté mal, el alta y la ficha del chat dejan de funcionar (el resto del Campus sigue igual). No se toca nada en el código.
Extensiones: Traveling, Daily y Pronunciation Boost
Hay tres cursos que no se venden como "Programa" sino como casillas en la misma fila de Ventas: Traveling, Daily y Pronunciation Boost. Van sobre la misma venta que el programa principal, así que comparten sus fechas: mismo inicio, mismo año de acceso.
- Casilla marcada → el Campus matricula al alumno también en ese curso, en la misma lectura en la que procesa su programa. No hace falta nada más.
- Casilla desmarcada después → el Campus le retira ese curso (queda como devolución); si se vuelve a marcar, lo recupera.
- Cualquier combinación vale: el Campus no comprueba si una extensión "pega" con un programa. Si alguien marca una por error, el alumno la ve y se corrige desmarcándola.
- Cada casilla tiene que estar conectada a un curso del Campus. Eso lo hace administración desde la ficha del curso, en el campo "Programa de Airtable", grupo Extensiones (ver Cargar contenido). Si una casilla está marcada pero no tiene curso conectado, la venta del programa se procesa igual y queda un aviso en la sincronización; el alumno simplemente no ve esa extensión hasta que se conecte.
Solo ventas nuevas
Las ventas anteriores a agosto de 2026 con extensiones marcadas no se han rematriculado hacia atrás. Si un alumno antiguo pregunta por su Traveling, hay que dárselo a mano o volver a procesar su fila.
No confundir con las "ampliaciones"
Una ampliación es alargar la fecha de fin de acceso de un alumno (se pone a mano en su ficha, ver Acceso y tutoría). Una extensión es uno de estos tres cursos extra. Son cosas distintas.
Si un alumno no aparece en el Campus
Antes de escalarlo, repasa esta lista (de arriba abajo):
- ¿Está la fila marcada para el Campus? Sin la casilla "Campus" marcada, no se sincroniza.
- ¿El correo es exacto? El alumno entra con el correo de Airtable; una errata lo deja fuera. (Ver también Iniciar sesión y la FAQ.)
- ¿El estado lo permite? El Estado Alumno de Airtable manda — ver Acceso y tutoría.
- ¿Han pasado unos minutos? La sincronización corre cada 10 minutos, a cualquier hora. Recién marcado, puede tardar ese rato en aparecer.
Si tras todo esto sigue sin aparecer, abre una incidencia con el correo del alumno y el enlace a su ficha de Airtable.
En resumen
- Airtable manda; el Campus refleja.
- El Campus va a buscar los datos cada 10 min; no espera a que Airtable avise.
- El disparador es marcar la casilla "Campus" en la fila, no una automatización.
- La ficha del chat se lee al momento y es solo para el equipo.
- El acceso va con un token guardado en Vercel, no en el código ni como app conectada.