Novedades
El endpoint /api/auto es ahora el camino más corto hacia una response funcional para cualquier URL. Apúntalo a un objetivo. Auto elige si ejecutar la request a través de Single, Proxy Finder o Browser, maneja los desafíos anti-bot cuando se encuentra con uno y devuelve una sesión que tu próxima llamada puede reutilizar.
Un endpoint. Cualquier objetivo. Sin cambios de modo por tu parte.
Esa es toda la idea. El resto de esta publicación trata sobre cómo funciona, cuánto cuesta y cuáles son las limitaciones.
Cómo funciona
Bajo Auto hay una escalera de peldaños (primero los baratos, luego los caros). En cada request, Auto sube por la escalera hasta que un peldaño entrega una response que tus reglas validate aceptan.
Los peldaños, en orden:
- Sesión en caché. Si Auto tiene una sesión activa para este host de una llamada anterior, la reproduce primero. Es el camino más barato.
- Proxy Finder. Una request de proxy rotativo. Útil para sitios protegidos principalmente por la reputación de la IP.
- Browser. Un renderizado completo que ejecuta JavaScript, resuelve los desafíos anti-bot y recopila las cookies que emite el sitio.
Una vez que un peldaño gana, Auto almacena la sesión que encontró: el id del proxy que usó, las cookies que emitió el sitio y el User-Agent. En la próxima llamada al mismo host, Auto prueba esa sesión primero. Si todavía funciona, pagas el peldaño barato, no el caro.
Una llamada mínima:
curl -X POST "https://api.foura.ai/api/auto" \
-H "Authorization: Bearer pk_live_..." \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/data",
"validate": { "status": { "accept": [200] } }
}'
Una response recortada:
{
"status": 200,
"data": "...",
"headers": [...],
"meta": {
"rung": "cache",
"solved": false,
"attempts": 1,
"credits": 2
},
"session": {
"proxy": "CLN1B8",
"cookies": [{ "name": "cf_clearance", "value": "..." }],
"userAgent": "..."
}
}
Dos campos importan para lo que construyas a continuación. meta.rung te dice qué ruta ganó. session es el triple que puedes llevar a una llamada /api/single para repetir la misma salida tú mismo. El campo proxy es un id opaco en base36 (sin IPs expuestas), seguro de registrar y seguro para pasar entre sistemas.
Impacto
Dos números importan aquí.
La primera llamada a un sitio protegido ejecuta el nivel Browser: renderiza, resuelve, recolecta cookies y te entrega la página. Eso cuesta unos 10 créditos. Una vez que Auto ha guardado en caché una sesión funcional para ese host, las llamadas posteriores pasan por Single a 2 créditos. Así que la segunda llamada es 5 veces más barata que la primera, y todas las siguientes siguen pagando la tarifa barata mientras la sesión se mantenga. Medimos esto en producción durante el lanzamiento: las salidas sin cookies (una vez encontradas) se repiten a exactamente 2 créditos por llamada frente a los 10 que solían costar cuando cada request pasaba por Proxy Finder.
El segundo número: los niveles fallidos no se cobran. Si Auto prueba tres proxies y cada uno devuelve 403 antes de que el cuarto entregue el contenido, solo cuentan los créditos del cuarto. Pagas por el contenido entregado, no por la búsqueda.
Ese es el valor central. El nivel caro se ejecuta una vez, el barato se ejecuta para siempre después, y no tienes que escribir la lógica de caché tú mismo.
Vale la pena señalar otros dos comportamientos porque resuelven dolores de cabeza reales en producción:
Los objetivos con restricción geográfica dejan de desperdiciar salidas. Cuando un sitio devuelve 451 (o un intersticial de bloqueo legal) para la mayoría de las salidas, Auto aprende qué países realmente entregaron contenido. En la siguiente llamada obtiene nuevas salidas de esos países primero y distribuye la carga concurrente entre ellos. Así que una sola salida afortunada no se sobrecarga y sufre rate limit.
La validación se ejecuta en cada nivel. Una página con contenido incorrecto (un bloqueo geográfico que devuelve estado 200 con un aviso legal como body) nunca cuenta como acierto. Si tu validate.data.fail dice "razones legales", Auto sigue trabajando hasta que un nivel lo supera. Ni el nivel en caché. Ni ningún nivel. Si nada pasa, obtienes un fallo honesto con la razón real.
Para usuarios avanzados
Algunos ajustes que importan una vez que pasas volumen a través de Auto.
timeout_ms es un presupuesto para toda la operación, no uno por nivel. El valor por defecto es de 120 segundos. Auto lo divide: cada subllamada obtiene min(su timeout natural, el presupuesto restante), y la cadena deja de lanzar nuevos niveles cuando queda muy poco tiempo. Establece 20,000 para trabajo interactivo de latencia. Deja el valor por defecto para rastreos masivos que toleran colas más largas.
forceProxy está activado por defecto. Auto nunca toca el objetivo desde la IP de origen de FourA a menos que establezcas forceProxy: false. Una advertencia: algunos sitios (Cloudflare interactivo con filtro de confianza de IP) de hecho funcionan mejor desde una IP de centro de datos limpia que desde una salida residencial de baja confianza. Por lo tanto, forceProxy: false puede hacer que ciertos objetivos sean más fáciles, no más difíciles. Si ves desafíos repetidos en un host específico, vale la pena probar a desactivar esto.
ignoreProxies es una lista de exclusión del cliente. Pasa los IDs de proxy que sepas que están quemados (de una session.proxy anterior que recibió rate limit de tu lado), y Auto los omitirá en todas partes: reutilización de sesiones activas, búsqueda de salida y la subllamada a Proxy Finder. Así que Auto no volverá a elegir la salida que le acabas de indicar que evite.
meta también te permite construir tus propios paneles sobre él: qué hosts alcanzaron el nivel del navegador hoy, intentos promedio por entrega, proporción de extracciones con desafíos resueltos frente a las limpias. Si un host específico sube repentinamente de 2 créditos a 10, esa es una señal de deterioro de sesión sobre la que puedes actuar antes de que afecte a tu factura.
Un ejemplo que combina los cuatro:
import requests
r = requests.post(
"https://api.foura.ai/api/auto",
headers={"Authorization": "Bearer pk_live_..."},
json={
"url": "https://example.com/product/9876",
"timeout_ms": 30000,
"forceProxy": True,
"ignoreProxies": ["CLN1B8", "K7X9AB"],
"validate": {
"status": {"accept": [200]},
"data": {"accept": ['"price":'], "fail": ["captcha", "legal reasons"]}
}
}
).json()
# If Auto delivered, keep the session for the next call to this host
if r.get("status") == 200 and "session" in r:
session = r["session"] # {proxy, cookies, userAgent}
print(r["meta"]["rung"], r["meta"]["credits"], r["meta"]["attempts"])
Para el propio esquema validate, consulta el recorrido anterior en Validate Rules Now Decide What Counts as Success.
Qué sigue
Hay dos cosas en la hoja de ruta para Auto en este momento.
La inspección de sesiones llega a continuación al Dashboard. Ahora mismo las sesiones que Auto mantiene por host viven dentro del servicio, y no hay nada que mirar cuando depuras un gasto desde tu lado. Estamos preparando una vista de sesión por host para que puedas ver las sesiones en caché, su antigüedad, cuánto tiempo vivirán y el historial de niveles detrás de cada una. Además de un botón para descartar una sesión a mano cuando tu objetivo cambia y sabes que la caché es incorrecta.
Después de eso, controles de costes más estrictos. Un límite estricto de créditos por request (nunca gastar más de X en esta llamada, fallar honestamente si lo hiciera) y un modo "single-only" para equipos cuyos objetivos nunca necesitan el nivel del navegador. Ambos están hoy detrás de flags.
El objetivo de Auto es que no pienses en a qué producto llamar. Eso no significa que no puedas inspeccionar lo que sucedió. Cada response incluye el nivel que utilizó y la sesión que construyó. Lee esos dos campos y sabrás exactamente por qué tus llamadas cuestan lo que cuestan.