Módulo 5: Airtable y Notion

Troubleshooting de Airtable y Notion

Siguiente →

Descripción de la cápsula

Tus workflows de Airtable y Notion funcionan en la prueba. En producción aparecen los problemas que no son de lógica: un error de "rate limit" cuando procesas una lista grande, un campo que "no existe" después de que alguien renombró una columna, un valor de selección rechazado, una integración que de pronto "no ve" una base.

Este es el manual de diagnóstico del módulo — y como trabaja dos herramientas, lo organiza por problema, no por herramienta, porque la mayoría de los problemas son comunes a ambas: las dos son bases de datos tipadas con APIs que limitan llamadas y estructuras que pueden cambiar. Cuando un problema es específico de una, se señala.

Los cuatro problemas que verás: rate limits, cambios de estructura, valores que la API rechaza (tipos y selects), y el acceso de la integración. No hay operación nueva — hay reconocimiento de síntomas.

Lo que vas a aprender

Al terminar esta cápsula serás capaz de:

  • ✅ Reconocer y resolver rate limits en Airtable y Notion
  • ✅ Diagnosticar errores por cambios de estructura (campos renombrados, movidos)
  • ✅ Resolver valores rechazados por tipo o por opción de selección inválida
  • ✅ Diagnosticar problemas de acceso de la integración
  • ✅ Leer los errores de ambas herramientas y clasificarlos rápido
  • ✅ Diseñar workflows que asumen las limitaciones de estas APIs

Problema 1: Rate limits

El síntoma

Errores de rate limit / 429. Pasa al procesar listas grandes o cuando varios workflows golpean la misma herramienta a la vez.

Por qué pasa

Tanto Airtable como Notion limitan cuántas llamadas puede hacer una integración por unidad de tiempo. Los números cambian y difieren entre las dos, pero a nivel práctico ambas son estrictas — más estrictas de lo que esperarías. Un workflow que hace una operación por item sobre una lista de cientos de registros choca con el límite rápido.

Las soluciones

1. Operaciones en lote (lo más efectivo). Ambas APIs pueden crear/actualizar varios registros en una sola llamada. En lugar de un Create por item, deja que el nodo reciba todos los items y los escriba juntos. Es la misma lección de Google Sheets (Módulo 1, cápsula 07): menos llamadas, no más reintentos.

2. Espaciar. Si tienes que procesar item por item, un nodo Wait entre operaciones reparte la carga.

3. Reintentar. Configura el nodo para reintentar si falla (Retry On Fail). Un rate limit es temporal — un reintento con espera lo supera.

4. Reducir frecuencia. Si un Schedule corre muy seguido y cada corrida hace muchas operaciones, baja el ritmo.

El principio (otra vez): trata cada llamada a la API como cara. Esto ya lo viste en Sheets y en Slack — es un principio transversal de toda integración. El mejor workflow hace menos llamadas.

Problema 2: Cambios de estructura

El síntoma

  • Un workflow que funcionaba empieza a fallar con "campo no encontrado" / "propiedad no existe"
  • El workflow escribe en el lugar equivocado, o deja campos vacíos
  • Ayer funcionaba, hoy no, y nadie tocó el workflow

Por qué pasa

Alguien editó la estructura de la tabla/base de datos:

  • Renombró un field (Airtable) o una propiedad (Notion)
  • Cambió el tipo de un campo (de texto a número, de select a texto)
  • Borró o reorganizó campos
  • Cambió las opciones de un select

Tu workflow depende de esos nombres y tipos. Si cambian, el workflow se desajusta — exactamente como pasaba con los encabezados de Google Sheets (Módulo 1, cápsula 07).

Las soluciones

1. Trata la estructura como un contrato. Una tabla/base de datos conectada a workflows no se edita casualmente. Si tu equipo la comparte, ponlo por escrito: "esto alimenta automatizaciones, no renombres campos ni cambies tipos sin avisar".

2. Si la estructura va a cambiar, planéalo. Cambia la tabla y actualiza los workflows en la misma sesión.

3. Considera tablas dedicadas. Las tablas que alimentan automatizaciones idealmente no son las mismas que la gente reestructura a mano cada semana.

Airtable y Notion son más estables que Sheets en esto — su estructura tipada no cambia "por accidente" tan fácil como una hoja libre. Pero "más estable" no es "inmune". El contrato sigue aplicando.

Problema 3: Valores que la API rechaza

El síntoma

  • Invalid value / errores que mencionan un campo o propiedad específica
  • Un Create o Update que falla solo con ciertos datos
  • "Funciona con datos de prueba, falla con datos reales"

Por qué pasa

Recuerda las cápsulas 03 y 04: Airtable y Notion validan por tipo. Esa validación, que es una ventaja (no entra basura), también significa que la API rechaza lo que no respeta el tipo. Las causas más comunes:

CausaEjemplo
Opción de select inexistenteMandas estado = "en revisión" pero el select solo tiene pendiente/aprobado/rechazado
Tipo equivocadoMandas "100" (texto) a un campo Number
Fecha mal formadaMandas 15/06/2026 a un campo Date que espera ISO
Relación con un nombre, no un IDMandas "Acme" a un campo de relación (cápsula 06)
Falta un campo obligatorioEn Notion, olvidas la propiedad Title

Las soluciones

1. Conoce el tipo antes de mapear. Antes de escribir a un campo, ten claro su tipo — y respétalo.

2. Normaliza los datos antes de escribir. Un Set previo que convierte tipos (Number()), formatea fechas (ISO 8601), y mapea valores a opciones válidas. Es el diseño defensivo del Módulo 1.

3. Para selects: mapea a opciones válidas. Si tus datos de entrada tienen valores que no coinciden con las opciones del select, usa un Switch o un mapeo para traducirlos. O crea las opciones que faltan en la herramienta.

4. Lee el error — dice qué campo. Ambas APIs señalan qué campo rechazó el valor. Eso te lleva directo al problema.

Esto enlaza con Sheets (números/fechas como texto) y con la cápsula 06 (relaciones con IDs). El principio es transversal: no pases datos crudos a un servicio estricto — normalízalos primero.

Problema 4: La integración no ve los datos

El síntoma

  • El nodo no encuentra una base / base de datos que sabes que existe
  • Error de permisos al leer o escribir
  • Funcionaba con una base y falla con otra nueva

Por qué pasa

Recuerda la cápsula 02 y su lección central: el token es una identidad sin permisos por defecto — solo ve lo que le diste acceso explícito. Las causas:

  • Airtable: la base no está en el acceso del token. Creaste una base nueva y no la agregaste.
  • Notion: la base de datos no se compartió con la integración. O se compartió una página pero la base de datos vive en otra rama del workspace.
  • Scopes insuficientes (Airtable): el token puede leer pero no escribir, o no ve el schema.

Las soluciones

1. Airtable: ve a la configuración del token y agrega la base al acceso. Verifica también que tenga los scopes de lectura y escritura.

2. Notion: abre la base de datos → menú ••• → Conexiones → agrega tu integración. Recuerda: la integración ve una página y todo lo anidado dentro.

3. Cuando crees una base/base de datos nueva, acuérdate de darle acceso antes de construir el workflow que la usa. Es el paso que todos olvidan.

Cómo leer un error

El error menciona...Es un problema de...Ve a...
rate limit, 429, too many requestsDemasiadas llamadasProblema 1
field not found, property does not exist, unknown fieldCambio de estructuraProblema 2
invalid value, invalid select, mención de un campo + tipoValor rechazado por tipo/selectProblema 3
not found (de una base/tabla entera), unauthorized, restrictedAcceso de la integraciónProblema 4
invalid token, 401Token inválido o revocadoRecrea/actualiza la credencial
(relación que no enlaza)Mandaste nombre en vez de IDCápsula 06

Como con Slack, los errores de Airtable y Notion son legibles — suelen decir qué campo y qué pasó. El primer reflejo siempre: leer el error completo antes de revisar tu lógica.

Trampas comunes

Trampa 1: Procesar listas grandes operación por operación

Qué pasa: 400 registros → 400 llamadas → rate limit.

Cómo evitar: Operaciones en lote — varios registros por llamada. Menos llamadas, no más reintentos.

Trampa 2: Renombrar un campo sin revisar los workflows

Qué pasa: Alguien renombra email a correo en Airtable. Todos los workflows que escribían a email se rompen.

Cómo evitar: La estructura es un contrato. No se renombra casualmente; si cambia, se actualizan los workflows en la misma sesión.

Trampa 3: No normalizar datos antes de escribir

Qué pasa: Mandas datos crudos del formulario y la API los rechaza por tipo.

Cómo evitar: Un Set previo que normaliza tipos, fechas y mapea selects a opciones válidas.

Trampa 4: Crear una base nueva y olvidar darle acceso

Qué pasa: Creas una base/base de datos, construyes el workflow, y el nodo "no la encuentra".

Cómo evitar: Dar acceso (Airtable: agregar al token; Notion: compartir con la integración) es el paso 2 obligatorio — hazlo antes de construir.

Trampa 5: Asumir que el error es tu lógica

Qué pasa: Pierdes tiempo revisando el workflow cuando el error decía claramente "field not found" o "rate limit".

Cómo evitar: Lee el error. Clasifícalo con la tabla. La mayoría de estos problemas no están en tu lógica.

Ejercicio: diagnostica cinco situaciones

Objetivo: practicar la clasificación rápida.

Tu tarea

Para cada situación, di (1) qué problema es y (2) el primer paso:

  1. Un workflow que sincroniza 600 registros empieza a fallar con 429 a la mitad.
  2. Un workflow de Airtable que funcionaba da unknown field: "telefono" desde ayer.
  3. Un Create en Notion falla con invalid value mencionando la propiedad Estado; el dato de entrada es "nuevo".
  4. El nodo de Notion no encuentra una base de datos que creaste esta mañana.
  5. Un Create en Airtable falla al escribir un campo de relación; le mandaste el nombre de la empresa.
Ver respuestas
  1. Rate limit (Problema 1). Primer paso: cambiar a operaciones en lote (varios registros por llamada) o espaciar con Wait.
  2. Cambio de estructura (Problema 2). Primer paso: verificar si alguien renombró el field telefono en Airtable; ajustar el workflow al nombre actual.
  3. Valor rechazado por select (Problema 3). Primer paso: verificar que "nuevo" sea una opción existente de la propiedad Estado; si no, crearla o mapear a una válida.
  4. Acceso de la integración (Problema 4). Primer paso: compartir la base de datos con la integración (menú ••• → Conexiones).
  5. Relación con nombre en vez de ID (cápsula 06). Primer paso: buscar la empresa primero (Search → Record ID) y mandar el ID al campo de relación.

Resumen y siguiente paso

  • Los problemas de Airtable y Notion son comunes a ambas — bases de datos tipadas con APIs que limitan llamadas y estructuras que pueden cambiar
  • Rate limits: operaciones en lote (varios registros por llamada) — el principio transversal de toda integración: menos llamadas
  • Cambios de estructura: la estructura es un contrato — no se renombra ni se cambia de tipo casualmente; más estable que Sheets, pero no inmune
  • Valores rechazados: la validación por tipo es una ventaja que también rechaza lo inválido — normaliza antes de escribir (tipos, fechas, selects a opciones válidas)
  • Acceso de la integración: el token solo ve lo que le diste acceso explícito — al crear una base nueva, dale acceso antes de construir el workflow
  • Los errores son legibles — léelos y clasifícalos antes de revisar tu lógica
  • 5 trampas: procesar uno por uno, renombrar sin revisar, no normalizar, olvidar dar acceso, asumir que es tu lógica

Antes de avanzar deberías poder:

  • Resolver un rate limit con operaciones en lote
  • Diagnosticar un error de "campo no encontrado"
  • Clasificar un error de Airtable o Notion en segundos

Lo que sigue (cápsula 08):

Tienes todas las piezas del módulo: conectar ambas, trabajar con cada una, elegir entre ellas, vistas/filtros/relaciones, y troubleshooting. El mini-proyecto las junta en un workflow que sincroniza datos entre Airtable y Notion — el caso que demuestra dominar las dos a la vez.

Recursos adicionales

  1. Airtable API: rate limits - Los límites oficiales de Airtable.
  2. Notion API: rate limits - Los límites oficiales de Notion.
  3. n8n: Retry On Fail - Configurar reintentos en los nodos.

Creado: Mayo 14, 2026 Versión: 1.0

← AnteriorVistas, Filtros y RelacionesSiguiente →Mini-Proyecto: Sincronizar Datos entre Airtable y Notion