Las reglas de validación ahora deciden qué cuenta como éxito

Las reglas validate de tu request ahora determinan cómo se clasifica cada resultado. Si declaras un 403 como aceptable, un 403 entregado cuenta como éxito, se factura como éxito y aparece en tu feed de Activity junto a tus 200.

Parece un detalle menor. Cambia la forma en que mides la precisión del scraping a escala.

Cómo funciona

Cada request a FourA recibe uno de siete resultados que definen la facturación y la analítica. Solo success es facturable. El resto se divide según el origen del fallo:

application_fail y application_error cuando el sitio de destino rechazó la conexión o devolvió un cuerpo de error
client_error cuando el request que enviaste estaba mal formado
service_fail, service_error y rate_limit cuando algo de nuestro lado bloqueó el request

Antes de este cambio, el éxito significaba exactamente una cosa: HTTP 200. Un 403 siempre era application_fail, incluso si sabías que ese 403 era la response que esperabas. (Algunas API de datos deportivos devuelven 403 para mercados con bloqueo geográfico, y esa es la señal que tu código está esperando).

Ahora tu bloque validate decide. El request ejecuta tus reglas durante el procesamiento. Si la response las cumple, el resultado es success.

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/api/feed",
    "unblocker": true,
    "validate": {
      "status": { "accept": [200, 403] },
      "data": { "fail": ["captcha", "Access Denied"] }
    }
  }'

Esto trata 200 y 403 como códigos de estado válidos. Si el body contiene un marcador de página de verificación o una cadena de acceso denegado, el request falla. Todo lo demás es success.

Dos reglas a recordar:

Sin validate, el comportamiento no cambia. Los requests que no declaran validación siguen facturándose solo con HTTP 200. Tú decides activarlo.
validate funciona en ambas direcciones. Las reglas de aceptación aprueban; las reglas de fallo rechazan. Se combinan. Así que puedes aceptar [200, 403] y aun así fallar cuando el body contenga el contenido incorrecto.

Impacto

El cambio es especialmente importante para los equipos cuyos objetivos devuelven responses distintos de 200 que realmente necesitan.

Ejemplos de requests que vemos a diario:

API de datos deportivos que devuelven 403 para mercados con bloqueo geográfico (siguen siendo datos útiles, sigue valiendo la pena registrarlos como éxito)
Endpoints de búsqueda de e-commerce que devuelven 404 cuando un SKU está agotado (una señal que tu código interpreta, no un fallo)
API de streaming y contenido parcial que devuelven 206

Antes del cambio, esos equipos llevaban su propio registro sobre nuestros logs de Activity. No podían confiar en la columna outcome porque su definición de éxito no coincidía con la nuestra. Se les facturaba según un número que en realidad no les servía.

Ahora la columna refleja la realidad. La pestaña Activity en tu Dashboard muestra lo que definiste como éxito, no lo que nosotros asumimos. Tus totales facturados coinciden con lo que tú mismo contarías (resultados iniciales: el cambio solo aplica hacia adelante, por lo que las filas anteriores de Activity conservan su clasificación original).

El efecto práctico en un trabajo de scraping: menos pasos de conciliación entre tu pipeline y nuestra factura. Si ya validabas el body de la response después de recibirlo, puedes trasladar ese contrato al propio request y dejar de mantener un conjunto paralelo de reglas de éxito/fallo fuera de nuestra API. Una sola definición de si un request se ganó su lugar en tu dataset, en lugar de dos que no coincidían.

Pero mantuvimos la red de seguridad. Si no envías un bloque validate, nada cambia. El clasificador recurre a "200 significa éxito", por lo que los requests que funcionaban ayer siguen funcionando igual hoy.

Para usuarios avanzados

validate acepta tres conjuntos de reglas que se ejecutan de forma independiente: status, headers y data. Cada uno admite listas opcionales de accept y fail.

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/product/9876",
    "followRedirects": 5,
    "unblocker": true,
    "validate": {
      "status": { "accept": [200, 304] },
      "headers": { "accept": { "content-type": "application/json" } },
      "data": { "accept": ["\"price\":"], "fail": ["maintenance", "captcha"] }
    }
  }'

Esto requiere:

Que el status sea 200 o 304
Que la response anuncie un content type JSON
Que el body contenga un campo de precio
Que el body no contenga un aviso de mantenimiento ni una página de verificación

Si alguna regla falla, el resultado es application_fail. Si todo pasa, es success. El clasificador se ejecuta dentro de la propia request, por lo que evitas el round trip que costaría un paso de validación independiente.

Combinado con followRedirects: sigue hasta cinco saltos y luego valida la response final. Un redireccionamiento engañoso desde una URL limpia hacia una página de verificación falla de forma limpia en lugar de contaminar tu dataset.

Y un consejo basado en la ejecución de nuestros propios scrapers: declara patrones data.fail de forma agresiva. Un 200 OK con una página de verificación en su interior es el modo de fallo silencioso más común en sitios protegidos. Trata el body como la fuente definitiva, no el status code.

Para ver el schema completo, la referencia de request lista cada campo validate y cómo se compone cada uno.

Próximos pasos

Estamos trabajando en primitivas de reglas más completas: coincidencias por regex para data, predicados estructurados de JSON-path y coincidencias de headers más flexibles. El principio sigue siendo el mismo. Tú declaras qué define el éxito; la API lo respeta de extremo a extremo, desde la request hasta tu factura.

Cuando tu scraper se rompe, debería hacerlo notar claramente. Y cuando funciona según las reglas que tú mismo escribiste, esa es una cifra en la que realmente puedes confiar.