Comprobaciones del sitio

Cuando un objetivo ejecuta una verificación de bots en el camino hacia la página que solicitaste, FourA te avisa. Cada request que encuentra una devuelve un campo que indica el sistema, si la verificación fue superada y (en caso afirmativo) la autorización que puedes reutilizar para que la siguiente llamada la omita.

Esta página es la referencia de esos campos. Para conocer la estrategia, consulta Sitios protegidos.

Dónde se encuentra el campo

La ausencia significa que no se reconoció nada. No interpretes un defense faltante como un fallo.

En Single y Proxy, el reporte requiere unblocker, que está habilitado por defecto. Con unblocker: false pediste la página exactamente como llegó, por lo que Single devuelve el challenge sin tocar y Browser lo renderiza sin resolverlo.

defense en Single y Proxy

{
  "status": 200,
  "data": "<!doctype html>...",
  "total_time": 3.61,
  "defense": {
    "vendor": "sgcaptcha",
    "solved": true,
    "present": ["sgcaptcha"],
    "ms": 3412,
    "hashes": 1048576,
    "complexity": 20,
    "cookie": "_I_=<clearance>"
  }
}

solved: false es el caso que justifica la bifurcación. FourA nunca presenta una página de desafío como contenido, por lo que el flag es tu señal de que el cuerpo necesita escalamiento en lugar de parseo.

retry: "refusal-cookies"

Algunos sitios no ejecutan un puzzle. Rechazan la primera request, establecen cookies en el rechazo y entregan la página real a cualquiera que devuelva esas cookies. Las páginas de artículos de eBay son el caso de referencia.

Cuando eso sucede, FourA las reenvía por ti y te entrega la página. La respuesta incluye entonces retry: "refusal-cookies":

{
  "status": 200,
  "data": "<!doctype html>...",
  "defense": {
    "vendor": "akamai",
    "solved": false,
    "present": ["akamai"],
    "retry": "refusal-cookies",
    "cookie": "bm_sv=...; dp1=..."
  }
}

Léelo de esta manera:

• solved se mantiene como false. Responder a un handshake no equivale a superar un challenge y nunca cambia el costo de la llamada. Se te factura por el request que realizaste.
• data es contenido real, no una página de challenge. Este es el único caso donde solved: false no significa que el body requiera escalación, motivo por el cual existe este campo.
• cookie es la sesión que entregó el sitio. Vuelve a enviarla del mismo modo en que reenviarías un clearance y las páginas siguientes omitirán el rechazo.
• Un retry y un clear pueden ocurrir en un mismo request. Si la respuesta del retry resultó ser un challenge que FourA puede superar, obtienes solved: true con los campos propios del proveedor y retry: "refusal-cookies" junto a ellos.

vendor muestra unknown cuando un retry generó el contenido y no se reconoció ningún sistema en el proceso. En ese caso, present es un array vacío.

defenses en Browser

{
  "status": 200,
  "body": "<!doctype html>...",
  "userAgent": "Mozilla/5.0...",
  "defenseSolved": true,
  "defenses": {
    "present": ["cloudflare"],
    "cleared": ["cloudflare"]
  }
}

Un nombre en present que nunca llega a cleared es un sistema que FourA puede reconocer pero aún no resolver. Esos nunca aumentan el precio de una llamada.

Proveedores

Qué se resuelve hoy

Todo lo demás en la lista se reconoce y se reporta, nada más. Esa división cambia a medida que FourA aprende a resolver más sistemas, así que consulta solved en lugar de asumir a partir de esta tabla.

Dos notas sobre casos límite:

• hcaptcha y recaptcha también son widgets de formulario ordinarios. Solo se reportan cuando la respuesta te bloqueó de verdad (403, 429 o 503), por lo que una página de pago con un widget de verificación en un formulario no reporta una defensa.
• Estar detrás de Cloudflare no es una defensa. cloudflare aparece cuando hay un desafío real o un artefacto de gestión de bots en la respuesta, no porque un sitio use Cloudflare.

Reutilizar una autorización

defense.cookie es todo el propósito del campo. Una autorización está vinculada a la salida que la obtuvo y al User-Agent que la obtuvo, por lo que si la repites a través del mismo par, la verificación no se vuelve a ejecutar.

import requests

API = "https://eu.api.foura.ai"
H = {"X-API-Key": "YOUR_API_KEY", "Content-Type": "application/json"}

# 1) First call pays for the clear.
first = requests.post(f"{API}/api/proxy/", headers=H, json={
    "maxTries": 5,
    "request": {"method": "GET", "url": "https://example.com/catalog"},
}).json()

defense = first.get("defense", {})
if defense.get("solved"):
    clearance = defense["cookie"]
    exit_id = first["proxy"]

    # 2) Follow-up pages skip the check: same exit, same clearance.
    for page in range(2, 6):
        r = requests.post(f"{API}/api/single/", headers=H, json={
            "method": "GET",
            "url": f"https://example.com/catalog?page={page}",
            "proxy": exit_id,
            "headers": [["Cookie", clearance]],
        }).json()
        print(page, r["status"])

La primera llamada asume el costo de la resolución. Cada replay es un request ordinario al precio habitual.

Tres cosas invalidan un replay:

1. Una salida diferente. Fija el proxy ID que devolvió la response de resolución. Consulta Reutilizar un Proxy entre Requests.
2. Un User-Agent diferente. Las responses de Browser devuelven el userAgent que utilizaron. Envíalo de vuelta junto con la cookie.
3. Expiración. Las autorizaciones tienen sus propios tiempos de vida, definidos por el destino. La de SiteGround dura alrededor de 30 días para todo el sitio; una autorización de Cloudflare suele ser mucho más corta. Trata una autorización como una caché: cuando los replays comiencen a devolver desafíos de nuevo, ejecuta una llamada limpia y toma la nueva.

Cuánto cuesta

Una comprobación resuelta cambia el precio únicamente en Browser:

Browser cobra 10 solo cuando el solver estuvo activo y un sistema fue resuelto efectivamente. Un sistema reconocido pero no resuelto cuesta 5, lo mismo que una página sin ninguna comprobación.

Una página de comprobación reconocida por FourA y servida con HTTP 200 (por ejemplo, el robot check de Amazon, la página de verificación de Reddit o el JavaScript check de Google Search) no se factura en ningún endpoint; la response la identifica en X-FourA-Check-Page.

Combínalo con validate

defense te indica que se encontró una comprobación. validate le indica a FourA cómo se ve la página real, lo que permite que un request falle en lugar de entregarte una página intermedia que devuelve HTTP 200.

{
  "method": "GET",
  "url": "https://example.com/product/42",
  "validate": {
    "data": {"accept": ["Add to cart"], "fail": ["Just a moment"]}
  }
}

En POST /api/auto/, validate es lo que evita que la secuencia acepte una página de desafío y la dé por completada.

Relacionado

• Sitios protegidos: Qué motor utilizar en cada nivel de protección
• Endpoints de la API: Referencia de request y response para los cuatro endpoints
• Reutilizar un proxy entre requests: Fija la salida a la que está vinculada una autorización
• Smart Fetch (Auto): Cómo encaja meta.solved en la secuencia
• Headers de respuesta: Dónde aparece el costo en créditos de una llamada