API JSON oculto del sitio: cómo encontrar endpoints internos y reducir el tráfico del parser

El parser extrae 400 KB de HTML por ocho campos que el sitio devuelve en su propia respuesta JSON de 8 KB. La diferencia de cincuenta veces no se trata de "código bonito", sino de la factura por proxies residenciales, donde pagas por cada gigabyte. Vamos a analizar cómo encontrar la API interna del sitio, qué impide replicarla en 2026 y cuándo es mejor abandonar esta idea.

¿Por qué buscar una API oculta si ya se puede parsear HTML?

Casi cualquier interfaz moderna — React, Vue, Angular, Next.js — primero carga el esqueleto de la página y luego obtiene los datos mediante solicitudes a sus propios endpoints. Estos endpoints no están documentados, pero existen, responden con JSON limpio y son accesibles sin un navegador sin cabeza.

Lo que obtienes al acceder a ellos:

• El tráfico disminuye drásticamente. En el análisis de una típica página de productos, la página HTML pesa alrededor de 400 KB, incluyendo el marcado, estilos y rastreadores, mientras que el endpoint JSON correspondiente pesa aproximadamente 8 KB, y tiene más campos: IDs internos, existencias, variantes del producto.
• No se necesita un navegador. Se elimina el renderizado de JavaScript, junto con el uso de memoria, procesador y decenas de solicitudes adicionales por fuentes y analítica.
• Los datos ya están estructurados. No hay selectores que se rompan por cambios en la clase CSS.
• Menos solicitudes, menos motivos para un baneo. Renderizar una página de catálogo en el navegador implica decenas de llamadas al sitio; la misma cantidad de datos a través de la API implica una sola.

Para un proyecto que utiliza proxies residenciales, esto es un ahorro directo: la tarifa se calcula por gigabytes, y pasar de renderizado a JSON generalmente reduce la factura más que cualquier truco para bloquear imágenes. Un tema relacionado es cómo reducir el tráfico del parser en 5 veces con otros métodos.

Paso a paso: cómo encontrar el endpoint

1. Primero verifica si hay una API oficial. Revisa /developers, /api, /docs del sitio objetivo. Una API pública documentada tiene versiones y avisa sobre deprecaciones; una privada cambia en silencio.
2. Abre DevTools (F12) y ve a la pestaña Network, asegurándote de que la grabación esté activada.
3. Activa el filtro Fetch/XHR. Esto elimina imágenes, fuentes y analítica, dejando solo las solicitudes de datos.
4. Limpia la lista para eliminar el ruido de la carga inicial.
5. Provoca los datos necesarios: desplázate por los resultados, haz clic en "siguiente página", aplica un filtro, abre una tarjeta. La solicitud que te interesa aparecerá en el momento de la acción.
6. Encuentra la respuesta con tus datos. La forma más rápida es Ctrl+F en la pestaña Network: busca un valor único que veas en la pantalla (artículo, precio exacto, parte del nombre) y observa qué solicitud lo generó.
7. Copiar la solicitud completa: clic derecho en la línea → Copiar → Copiar como cURL. Luego convierte a código a través de curlconverter — así no perderás ningún encabezado.

Rutas características a las que debes prestar atención primero: /api/, /v1/, /v2/, /search, /products, /listings, /graphql.

Caso especial: sitios en Next.js

Aquí los datos a menudo no requieren una solicitud separada; están directamente en el HTML. En el antiguo Pages Router, esto es el bloque __NEXT_DATA__. En el App Router (Next.js 13 y versiones posteriores), los datos para la hidratación están distribuidos a través de llamadas self.__next_f.push() en varios nodos de script — este es el payload serializado de los Componentes del Servidor de React. Desglosarlo manualmente es incómodo: los chunks se refieren entre sí a través de prefijos $ y pueden cortarse a la mitad de una cadena. Para Python, hay una biblioteca nextflight que analiza tanto el Flight-payload del HTML como la respuesta RSC cruda (solicitud con el encabezado RSC: 1), y sugiere buscar en ella por nombres de claves en lugar de por índices de matriz — así el parser sobrevive a la redeploy del sitio.

Reversa de parámetros: paginación y filtros

El endpoint encontrado casi siempre está parametrizado. Se encuentran tres esquemas:

• Por páginas: ?page=3&per_page=20
• Desplazamiento y límite: ?offset=40&limit=20
• Cursor: ?after=<token>&limit=20 — el token de la siguiente página llega en el cuerpo de la respuesta anterior

Tres reglas que ahorran horas de depuración:

• Detente en un lote vacío, no en un número de páginas precalculado: el contador total en las API privadas miente más a menudo de lo que desearías.
• Verifica el tamaño real del lote. Si solicitaste 100 y recibiste 20, significa que el endpoint tiene su propio límite, y tu aritmética de páginas ya es incorrecta.
• No accedas a la página 500. La paginación profunda casi siempre es cortada por el servidor; en su lugar, corta la selección con filtros — por categoría, por rango de precios, por fecha.

Por qué cURL desde el navegador funciona, pero tu código no

Este es el punto de fallo más común, y la razón casi siempre es una: encabezado perdido. El cURL copiado lleva todo el contexto de la solicitud, mientras que un cliente hecho a mano no.

Lo que generalmente resulta ser obligatorio:

• Encabezados personalizados con el prefijo X- — X-CSRF-Token, X-Requested-With: XMLHttpRequest y varios X-*-Token que el frontend inserta automáticamente. Sin ellos, recibirás una respuesta en el rango de 400–500.
• Referer — un encabezado contextual que se genera por la acción del usuario. Muchos endpoints verifican que la solicitud "venga de su propia página".
• Authorization: Bearer <JWT> — un token de corta duración, generalmente de 15 a 60 minutos. Hardcodearlo no tiene sentido: necesitas saber cómo obtener uno nuevo.
• Cookies de sesión — manténlas en un objeto de sesión, no las copies manualmente.
• Correcto Content-Type para POST: application/json y application/x-www-form-urlencoded codifican el cuerpo de manera diferente, y una discrepancia con el tipo declarado rompe la solicitud en silencio.

¿Dónde buscar los tokens si no están en las cookies? En el código fuente HTML dentro de <script> (buscando un valor conocido a través de Ctrl+F), en los bundles de JavaScript, en localStorage o IndexedDB — pestaña Application en DevTools.

Trampas que se descubren tarde

La API privada cambia sin previo aviso. No tiene versionado, promesas de compatibilidad ni soporte: el equipo de frontend renombra un campo el jueves por la noche, y tu parser recoge vacío. La protección no es un "selector confiable", sino el control de la estructura: verifica que los campos obligatorios estén presentes y del tipo correcto; monitorea la proporción de valores vacíos y la cantidad de registros en la ejecución; omite registros corruptos, pero alerta si el defecto supera el 10%; guarda respuestas crudas para tener algo con qué comparar después.

La API a veces está más protegida que la página. Esto ocurre regularmente: el HTML se entrega sin problemas, pero en /api/ hay un anti-bot que verifica tanto el fingerprint de TLS como la combinación de encabezados. Entonces, el ahorro de tráfico se convierte en un aumento de la proporción de solicitudes fallidas, y la ganancia se consume.

Solicitudes firmadas. Si en los parámetros ves algo como sign, hash o _s, el frontend calcula la firma en JavaScript. Reproducirla es un proyecto separado, y a menudo es más barato quedarse con HTML.

Restricciones de frecuencia. Los endpoints privados no están diseñados para un flujo continuo: mantén 1–2 solicitudes por segundo, establece tiempos de espera separados para conexión y lectura (por ejemplo, 5 y 30 segundos), repite solo errores transitorios — 429, 500, 502, 503, 504 — y no toques 401 y 404. La demora exponencial con jitter es obligatoria, de lo contrario, todos los workers irán a un segundo ciclo al mismo tiempo. Más detalles en el análisis de tiempos de espera y lógica de reintento para proxies.

Marco legal. Los endpoints públicos no autenticados son una situación, el acceso a la cuenta es fundamentalmente diferente: registrarse significa aceptar el acuerdo de usuario. Los datos personales están sujetos al GDPR independientemente de cuán fácilmente se obtengan. Los hechos — precios, características, disponibilidad — no están protegidos por derechos de autor, a diferencia de los textos e imágenes.

Cuándo quedarse con HTML

Una API oculta no siempre es una ventaja. Permanece en el análisis de páginas si:

• el sitio es del lado del servidor y no hay ninguna API interna;
• el endpoint requiere firma o rotación de tokens — mantenerlo es más caro que la página;
• la API tiene una protección más fuerte que las páginas públicas;
• necesitas el resultado final que el frontend compila de varias fuentes;
• manejas decenas de sitios: una única línea de producción HTML se escala mejor que un zoológico de APIs privadas con peculiaridades individuales.

Qué tipo de proxy usar para el parsing de API

Pasar a JSON cambia el cálculo, porque se desplaza el cuello de botella: el tráfico se vuelve escaso, pero las exigencias de calidad de IP y estabilidad de sesión aumentan.

• Endpoint abierto sin autorización y sin anti-bot. Aquí son suficientes proxies de centro de datos: el volumen de datos es pequeño, no es necesario pagar por residenciales.
• Endpoint detrás de un anti-bot o vinculado a una sesión. Se necesitan proxies residenciales con sesión persistente: el token, las cookies y la IP deben coincidir a lo largo de toda la cadena, de lo contrario, el servidor restablecerá la sesión en la segunda solicitud. Aun así, la cuenta seguirá siendo modesta: los gigabytes en modo JSON se consumen lentamente.
• Datos de una aplicación móvil. Si la versión web está cerrada y la aplicación entrega lo mismo de manera más sencilla, los endpoints se buscan a través de la interceptación del tráfico — este es un procedimiento separado, analizado en el artículo sobre la búsqueda de la API oculta de una aplicación móvil a través de mitmproxy.

En resumen

Veinte minutos en DevTools a menudo reemplazan días de lucha con un navegador sin cabeza: filtro Fetch/XHR, búsqueda por valor visible, Copiar como cURL — y tienes una solicitud funcional. Luego, se resuelven los detalles: trasladar todos los encabezados, desglosar el esquema de paginación, establecer la validación de la respuesta y evaluar fríamente si el endpoint no está más protegido que la propia página. Donde la API privada funciona, reduce tanto el volumen de tráfico como el número de solicitudes — es decir, reduce tanto el costo de los proxies como la probabilidad de un baneo.