Dejen de scrapear autos: lecciones tras quemar miles de peticiones en APIs oficiales

Hace dos años cometí un error de novato con la billetera de un cliente. Teníamos un sistema montado con proxies residenciales y navegadores headless extrayendo publicaciones de vehículos usados. Todo marchaba de maravilla hasta que la plataforma actualizó sus protecciones anti-bot un martes a las 3:00 de la madrugada. El resultado: 1.400 dólares quemados en IPs bloqueadas en menos de seis horas y una base de datos vacía al inicio de la jornada comercial.

Ese día decidimos cerrar el ciclo del web scraping salvaje en GuardLabs. Nos fuimos directo a tocar la puerta institucional: integrar el auto ria api de manera legal y estructurada. Parecía la salvación. Sin bloqueos raros, sin resolver captchas imposibles, datos limpios en formato JSON. Pero la realidad de producción tiene su propio costo oculto.

Trabajar con interfaces oficiales de marketplaces automotrices te quita el dolor de cabeza de las trampas de Cloudflare, es verdad. Sin embargo, te enfrenta a un problema de ingeniería mucho más técnico: el balance de sondeo (polling), las mutaciones silenciosas de datos y los límites matemáticos de tu cuota mensual.

El problema del sondeo ingenuo: la cuota no perdona

Cuando la gente piensa en una API oficial, imagina webhooks mágicos que te avisan el milisegundo exacto en que alguien publica un Toyota Corolla a buen precio. En la vida real, casi ningún marketplace automotriz te ofrece webhooks para eventos públicos. Tienen que proteger su infraestructura. Así que te obligan a hacer sondeo periódico (polling).

Aquí es donde la mayoría de los desarrolladores quiebran el presupuesto. Si tienes 30.000 vehículos bajo monitoreo y quieres frescura casi instantánea, un bucle ingenuo que revise cada minuto agotará cualquier límite permitido antes del mediodía. Peor aún si tu auto ria api key tiene asignada una cuota fija de peticiones por segundo o por mes comercial.

La solución no es pedir más cuota a ciegas. La solución es entender la física del mercado que estás vigilando.

En autos usados, el 80% de las publicaciones no sufren cambios de precio en sus primeras 48 horas. Sin embargo, las verdaderas oportunidades —autos por debajo del valor de mercado puestos por particulares urgidos de efectivo— se venden en menos de tres horas. Si tratas a todos los registros por igual, estás desperdiciando computación.

Nosotros dividimos el sondeo en tres niveles:

Primero, el feed general de novedades: solo consultamos los IDs más recientes cada pocos minutos. Es una petición ligera que consume muy poco ancho de banda. Segundo, el rastreo de cambios de precio: solo verificamos publicaciones activas durante las horas pico de tráfico local (entre las 9:00 y las 19:00), espaciando las llamadas según la antigüedad del anuncio. Un anuncio que lleva 45 días publicado rara vez cambia de precio a las dos de la mañana de un domingo. Tercero, la verificación de bajas: si un auto desaparece del listado de búsqueda, hacemos una sola petición directa para confirmar si se marcó como vendido o si simplemente expiró. Ese simple esquema redujo nuestro consumo de peticiones en un 68% manteniendo la detección de gangas intacta.

Payloads que cambian sin aviso previo

Existe una fantasía en el desarrollo moderno de software: las versiones semánticas de las APIs. En teoría, si una plataforma pasa de v1 a v2, te lo notifican con meses de anticipación. En la práctica de plataformas masivas de clasificados, los equipos internos empujan cambios a producción que rompen tus parsers sin cambiar el número de versión del endpoint.

Un viernes cualquiera, el campo donde recibías el kilometraje pasa de ser un entero a una cadena con texto ("120.000 km"). O peor: agregan estados nuevos para daños mecánicos que tu esquema relacional no contemplaba y tu base de datos empieza a rechazar inserciones silenciosamente. Mientras tanto, tu cliente asume que el sistema está corriendo porque el servidor devuelve código HTTP 200.

Aprendimos esto a los golpes. Ahora ninguna respuesta cruda entra directo a la lógica de negocio. Diseñamos adaptadores defensivos intermedios. Si un campo crítico cambia de tipo, el sistema no colapsa: guarda el objeto crudo en un almacén de respaldo, emite una alerta métrica a nuestro panel y procesa el resto de los datos válidos con valores por defecto. Si vas a monitorear activos de alto valor, no puedes permitirte que un campo nulo de color de tapicería detenga el pipeline de alertas financieras.

Límites de proveedor frente a la rentabilidad del cliente

Muchos fundadores nos buscan diciendo: "Quiero monitorear todo el mercado nacional cada 30 segundos". Mi respuesta siempre es la misma: ¿pueden tus operadores llamar a 500 vendedores por minuto? Por supuesto que no.

Las tarifas empresariales de acceso a datos existen para proteger los servidores del proveedor, pero también actúan como un filtro de sensatez de negocio. Pagar por miles de llamadas extra para tener una latencia de 10 segundos en lugar de 3 minutos casi nunca se traduce en más compras cerradas en el mundo automotriz. Lo que sí genera valor es la consistencia: que tus alertas nunca se caigan, que los datos de kilometraje y precio histórico sean certeros y que no dependas de scripts frágiles de Selenium que dejan de funcionar con cualquier cambio de CSS.

Construir sobre bases de datos oficiales te permite firmar acuerdos de nivel de servicio (SLA) reales con tus clientes o con tu propio equipo interno. Dejas de jugar a las escondidas con los firewalls y te concentras en lo que de verdad importa: detectar discrepancias de precios antes que la competencia.

Si su equipo necesita infraestructura robusta para seguir inventarios o cazar oportunidades en Ucrania sin lidiar con bloqueos de IP ni arquitectura de reintentos, en GuardLabs montamos canales dedicados: conozcan nuestro servicio de Мониторинг объявлений auto.ria через официальный API y hablemos de números claros para su caso de uso.