Logs

Todo request que llega al API Gateway queda registrado. No una muestra, no solo las fallas — todos, incluidos los que se rechazaron antes de tocar un dato.

Eso hace de la pestaña Logs el primer lugar donde mirar cuando una integración se porta mal, y el único que puede decirte qué mandó realmente quien llamó, en vez de lo que cree que mandó.

La encontrás en API Gateway → Logs.

Qué guarda una entrada

Los dos últimos están en la vista de detalle y no en la lista, y son la razón por la que el log vale la pena: podés leer el JSON exacto que mandó un llamador, lo que zanja la mayoría de las discusiones de "la API está rota" en unos diez segundos.

El registro ocurre después de enviar la respuesta, así que nunca hace más lento a un request.

Los cinco tipos

Tenerlos separados importa más de lo que parece. Un workspace que se ve ocupado suele estarlo de una de estas cinco formas, y la columna de tipo te dice cuál sin leer un solo payload.

Tipos de auth, y qué implican

La presencia de un usuario final en una fila es la señal útil: significa que ese request estuvo sujeto a los scopes y row filters de esa persona, no a los de una credencial. Si una fila que esperabas filtrada no muestra usuario final, la llamada se hizo con una key de aplicación y no aplicó ningún filtro por usuario.

Filtros

La lista filtra por credencial, usuario final, rango de estado y rango de fechas, con búsqueda libre sobre principal, correo del usuario final, IP de origen y mensaje de error encima.

El rango de estado es el primero al que recurrir. 400–499 son todos los requests rechazados; recorrer eso es cómo encontrás un cliente que viene fallando en silencio hace una semana porque nadie mira sus logs.

Qué nunca aparece acá

Tres cosas, todas a propósito:

• Corridas del Playground. Ejecutar una consulta en el Playground no escribe nada en el log y no cuenta contra tu cuota. Si estás depurando mirando esta pestaña, una corrida del Playground nunca va a aparecer — llamá al endpoint de verdad.

• Interior de las automatizaciones. Un webhook muestra una entrada por la llamada entrante. Lo que después hicieron las automatizaciones suscritas está en el historial de ejecuciones, no acá.

• El contexto de conversación con la IA. Una entrada MCP registra la llamada a la herramienta — qué tabla, qué operación — y no lo que alguien le escribió al asistente.

Los logs no se pueden borrar

No hay eliminar, ni purga masiva. Eso es lo que hace del log una traza de auditoría y no una comodidad de depuración: una entrada no la puede sacar quien la causó, administrador incluido.

Depurar con esto

"La integración dejó de funcionar." Filtrá por su credencial y ordená por más reciente. Si no hay ninguna entrada, el request nunca llegó — eso es un problema de URL, DNS o firewall del lado de ellos, no de permisos del tuyo. Si hay entradas, el estado te dice qué capa las rechazó.

"Funciona en el Playground pero no desde mi app." Casi siempre una de tres cosas, y el log las distingue: un 403 SCOPE_VIOLATION significa que los scopes de esa credencial difieren de la que probaste; un 401 significa key equivocada, vencida o revocada; y ninguna entrada significa que tu app no está llegando al gateway.

"Nos están limitando." Filtrá por estado 429. El patrón en las marcas de tiempo te dice si es una sobrecarga sostenida o un cliente en bucle de reintentos.

"Un cliente dice que ve datos de otro." Filtrá por su id de usuario final. Cada entrada muestra qué pidió y qué volvió — y si el row filter de su rol se aplicó siquiera.

Un `403` sin usuario final en una llamada de cara al usuario merece una segunda mirada por sí solo: normalmente significa que la app cayó de vuelta a su API key en algún punto, y el aislamiento por usuario no estuvo vigente para ese request.

Siguiente

• Uso y cuotas — cuánto cuestan estas llamadas y qué pasa al llegar al límite.

• Modelo de Seguridad — a qué capa corresponde cada código de estado.