← Todos los artículos
Actualización de producto 5 min de lectura

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

Declare qué responses cuentan como éxito mediante reglas de validación. Las responses que no sean 200 y que acepte ahora se facturan correctamente y se muestran como éxito en su feed de Activity.

apivalidationoutcomesbilling

Las reglas validate de su request ahora determinan cómo se clasifica cada resultado. Declare un 403 como aceptable, y un 403 entregado contará como éxito, se facturará como éxito y aparecerá en su feed de Activity junto con sus responses 200.

Esto parece un detalle menor. Cambia la forma de medir la precisión del scraping a escala.

Cómo funciona

Cada request a FourA recibe uno de siete resultados que deciden la facturación y las métricas. 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ó la petición o devolvió un cuerpo de error
  • client_error cuando el request que envió 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ía que ese 403 era la response que quería. (Algunas API de datos deportivos devuelven 403 para mercados con restricciones geográficas, y esa es la señal que su código está esperando).

Ahora su bloque validate decide. El request ejecuta sus reglas durante la ejecución. Si la response las cumple, 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 200 y 403 como códigos de estado válidos. Si el cuerpo contiene una marca de CAPTCHA o una cadena de acceso denegado, el request falla. Cualquier otra cosa es success.

Two rules to remember:

  1. Sin validate, el comportamiento no cambia. Los requests que no declaran validación se siguen facturando solo con HTTP 200. Usted decide activarlo.
  2. validate funciona en ambos sentidos. Las reglas de aceptación aprueban; las reglas de fallo rechazan. Se combinan. Así que puede aceptar [200, 403] y aun así fallar si el cuerpo contiene el contenido incorrecto.

Impacto

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

Ejemplos de requests que vemos a diario:

  • API de datos deportivos que devuelven 403 para mercados con restricciones geográficas (siguen siendo datos útiles, sigue valiendo la pena registrarlos como éxito)
  • Endpoints de búsqueda de comercio electrónico que devuelven 404 cuando un SKU está agotado (una señal que su código lee, no un fallo)
  • API de streaming y contenido parcial que devuelven 206

Antes del cambio, esos equipos llevaban su propio registro por encima de 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 en función de una cifra que en realidad no les interesaba.

Ahora la columna refleja la realidad. La pestaña de Activity en su Dashboard muestra lo que usted definió como éxito, no lo que nosotros supusimos. Sus totales facturados coinciden con lo que usted mismo contaría (resultados iniciales: el cambio se aplica solo hacia adelante, por lo que las filas de Activity más antiguas conservan su clasificación original).

El efecto práctico en una tarea de scraping: menos pasos de conciliación entre su pipeline y nuestra factura. Si ya realizaba la validación en el cuerpo de la response a posteriori, puede trasladar ese contrato al propio request y dejar de mantener un conjunto paralelo de reglas de aprobación/fallo fuera de nuestra API. Una sola definición de si un request se ganó su lugar en su conjunto de datos, en lugar de dos que no coincidían.

Pero mantuvimos la red de seguridad. Si no envía un bloque validate, nada cambia. El clasificador vuelve a "200 significa éxito", por lo que los requests que funcionaban ayer funcionan de la misma manera 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 "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 de precio
  • 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 se cumple, es success. El clasificador se ejecuta dentro del propio request, por lo que se ahorra el viaje de ida y vuelta que costaría un paso de validación independiente.

Combinado con followRedirects: sigue hasta cinco saltos y luego valida la response final. Un engaño de cambio de dirección de una URL limpia a una barrera de CAPTCHA falla limpiamente en lugar de contaminar su conjunto de datos.

Y un consejo basado en la ejecución de nuestros propios scrapers: declare 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. Trate el cuerpo como la fuente de verdad, no el código de estado.

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

Qué sigue

Estamos trabajando en primitivas de reglas más completas: comparadores regex para data, predicados JSON-path estructurados y coincidencias de headers más flexibles. El principio sigue siendo el mismo. Usted declara cómo es el éxito; la API lo respeta de extremo a extremo, desde el request hasta su factura.

Cuando su scraper se rompa, debería hacerlo notar con claridad. Y cuando funcione según las reglas que usted mismo escribió, ese será un número en el que realmente podrá confiar.