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

Las reglas validate de tu request ahora dirigen cómo se clasifica cada resultado. Declara un 403 como aceptable, y un 403 entregado contará como éxito, se facturará como éxito y aparecerá en tu feed de Actividad junto a tus 200.

Esto parece pequeño. Cambia cómo mides la precisión del scraping a escala.

Cómo funciona

Cada request a FourA obtiene uno de siete resultados que deciden la facturación y las analíticas. Solo success es facturable. El resto se divide según quién sea el responsable del fallo:

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

Antes de este cambio, éxito significaba exactamente una cosa: HTTP 200. Un 403 siempre era application_fail, incluso si sabías que 403 era la response que querías. (Algunas APIs de datos deportivos devuelven 403 para mercados con restricción geográfica, y esa es la señal que tu código espera).

Ahora tu bloque validate decide. La request ejecuta tus reglas durante la ejecución. Si la response las satisface, el resultado es success.

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "Authorization: Bearer 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 a 200 y 403 como códigos de estado válidos. Si el cuerpo contiene un marcador de CAPTCHA o una cadena de acceso denegado, la request falla. Todo lo demás es success.

Dos reglas para recordar:

Sin validate, el comportamiento no cambia. Las requests que no declaran validación aún se facturan solo en HTTP 200. Tú decides si participar.
validate funciona en ambas direcciones. Las reglas de aceptación pasan; las reglas de fallo rechazan. Se componen. Así que puedes aceptar [200, 403] y aun así fallar cuando el cuerpo contiene el contenido incorrecto.

Impacto

El cambio importa más para los equipos cuyos objetivos devuelven responses distintas a 200 que realmente quieren.

Ejemplos de requests que vemos a diario:

APIs de datos deportivos que devuelven 403 para mercados con restricción geográfica (datos aún útiles, aún vale la pena registrar como éxito)
Endpoints de búsqueda de comercio electrónico que devuelven 404 cuando un SKU está agotado (una señal que tu código lee, no un fallo)
APIs de streaming y contenido parcial que devuelven 206

Antes del cambio, esos equipos llevaban su propia contabilidad encima de nuestros registros de Actividad. No podían confiar en la columna outcome porque su definición de éxito no coincidía con la nuestra. Se les facturaba por un número que realmente no les importaba.

Ahora la columna refleja la realidad. La pestaña de Actividad en tu Dashboard muestra lo que definiste como éxito, no lo que nosotros adivinamos. Tus totales facturados coinciden con lo que tú mismo contarías (resultados iniciales: el cambio solo se aplicó hacia adelante, por lo que las filas de Actividad antiguas mantienen 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 estabas ejecutando validación en el cuerpo de la response a posteriori, puedes mover ese contrato a la propia request y dejar de mantener un conjunto paralelo de reglas de paso/fallo fuera de nuestra API. Una definición de si una request ganó su lugar en tu dataset, en lugar de dos que no estaban de acuerdo.

Pero mantuvimos la red de seguridad. Si no pasas un bloque validate, nada cambia. El clasificador vuelve a usar "200 significa éxito" para que las requests que funcionaban ayer funcionen igual hoy.

Para usuarios avanzados

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

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "Authorization: Bearer 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 estado sea 200 o 304
Que la response anuncie un tipo de contenido JSON
Que el cuerpo contenga un campo price
Que el cuerpo no contenga un aviso de mantenimiento o una trampa de CAPTCHA

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 te saltas el viaje de ida y vuelta que costaría un paso de validación separado.

Combinado con followRedirects: sigue hasta cinco saltos, luego valida la response final. Un cambio engañoso de una URL limpia a una puerta de CAPTCHA falla limpiamente en lugar de contaminar tu dataset.

Y un consejo de ejecutar nuestros propios scrapers: declara patrones data.fail de forma agresiva. Un 200 OK con un CAPTCHA dentro es el modo de fallo silencioso más común en sitios protegidos. Trata al cuerpo como definitivo, no al código de estado.

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

Qué sigue

Estamos trabajando en primitivas de reglas más ricas: coincidencias de expresiones regulares para data, predicados JSON-path estructurados y coincidencias de headers más flexibles. El principio sigue siendo el mismo. Tú declaras cómo se ve el éxito; la API lo respeta de principio a fin, desde la request hasta tu factura.

Cuando tu scraper se rompe, debería ser ruidoso al respecto. Y cuando funciona contra reglas que tú mismo escribiste, ese es un número en el que realmente puedes confiar.