O que há de novo
O endpoint /api/auto é agora o caminho mais curto para obter uma response funcional para qualquer URL. Aponte para um alvo. O Auto escolhe se deve executar a request via Single, Proxy Finder ou Browser, lida com desafios anti-bot quando encontra um e devolve uma session que sua próxima chamada pode reutilizar.
Um endpoint. Qualquer alvo. Sem troca de modo do seu lado.
Essa é toda a ideia. O restante deste post aborda como funciona, quanto custa e onde estão os pontos de atenção.
Como funciona
Sob o Auto, há uma escala de etapas (baratas primeiro, caras por último). A cada request, o Auto sobe essas etapas até que uma entregue uma response que suas regras validate aceitem.
As etapas, em ordem:
- Cached session. Se o Auto tiver uma session ativa para este host de uma chamada anterior, ele a reutiliza primeiro. Caminho mais barato.
- Proxy Finder. Uma request com proxy rotativo. Bom para sites protegidos principalmente por reputação de IP.
- Browser. Uma renderização completa que executa JavaScript, resolve desafios anti-bot e coleta os cookies emitidos pelo site.
Assim que uma etapa tem sucesso, o Auto armazena a session encontrada: o ID do proxy utilizado, os cookies emitidos pelo site e o User-Agent. Na próxima chamada para o mesmo host, o Auto tenta essa session primeiro. Se ela ainda funcionar, você paga pela etapa mais barata, não pela cara.
Uma chamada mínima:
curl -X POST "https://api.foura.ai/api/auto" \
-H "X-API-Key: pk_live_..." \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/data",
"validate": { "status": { "accept": [200] } }
}'
Uma resposta reduzida:
{
"status": 200,
"data": "...",
"headers": [...],
"meta": {
"rung": "cache",
"solved": false,
"attempts": 1,
"credits": 2
},
"session": {
"proxy": "CLN1B8",
"cookies": [{ "name": "cf_clearance", "value": "..." }],
"userAgent": "..."
}
}
Dois campos importam para o que você constrói a seguir. meta.rung informa qual caminho venceu. session é a trinca que você pode passar para uma chamada /api/single para reproduzir a mesma saída por conta própria. O campo proxy é um id opaque em base36 (sem IPs puros), seguro para registrar em logs e seguro para trafegar entre sistemas.
Impacto
Dois números importam aqui.
A primeira chamada para um site protegido executa a etapa Browser: renderizar, resolver, coletar cookies, entregar a página para você. Isso consome cerca de 10 créditos. Depois que o Auto armazena em cache uma sessão funcional para esse host, as chamadas seguintes a reproduzem: via Single a 2 créditos, ou via Proxy Finder a 4 quando os cookies da sessão funcionam a partir de qualquer endereço. Portanto, a segunda chamada é até 5x mais barata que a primeira, e cada uma subsequente continua pagando a taxa econômica enquanto a sessão se mantiver válida. Medimos isso em produção durante o rollout: saídas sem cookies (uma vez encontradas) são reproduzidas exatamente a 2 créditos por chamada, contra os 10 que custavam quando toda requisição passava pelo Proxy Finder.
O segundo número: etapas com falha não são faturadas. Se o Auto tentar três proxies e cada um retornar 403 antes que o quarto entregue, apenas os créditos do quarto são cobrados. Você paga pelo conteúdo entregue, não pela busca.
Esse é o valor principal. A etapa cara roda uma vez, a etapa econômica roda a partir de então, e você não precisa escrever a lógica de cache por conta própria.
Outros dois comportamentos merecem destaque porque resolvem problemas reais de produção:
Alvos com geo-bloqueio param de desperdiçar saídas. Quando um site retorna 451 (ou um aviso intermediário de bloqueio legal) para a maioria das saídas, o Auto aprende quais países realmente entregaram conteúdo. Na chamada seguinte, ele busca primeiro saídas novas desses países e distribui a carga concorrente entre elas. Assim, uma única saída que funcionou por sorte não fica sobrecarregada sofrendo rate limit.
O Validate roda em cada etapa. Uma página com conteúdo incorreto (um geo-bloqueio que retorna status 200 com um aviso legal no body) nunca conta como sucesso. Se a sua validate.data.fail contiver "legal reasons", o Auto continua tentando até que uma etapa passe na validação. Nem a etapa em cache. Nem qualquer etapa. Se nada passar, você recebe uma falha real com o motivo exato.
Para Usuários Avançados
Alguns ajustes que importam assim que você enviar volume pelo Auto.
timeout_ms é um orçamento para a operação inteira, não por etapa. O padrão é 120 segundos. O Auto o fraciona: cada subchamada recebe min(seu timeout natural, o orçamento restante), e a sequência para de iniciar novas etapas assim que resta pouco tempo. Defina 20.000 para tarefas que exigem latência interativa. Mantenha o padrão para crawls em lote que toleram caudas mais longas.
forceProxy fica ativado por padrão. O Auto nunca acessa o alvo a partir do IP de origem da FourA, a menos que você configure forceProxy: false. Uma ressalva: alguns sites (Cloudflare interativo com validação de reputação de IP) na verdade funcionam melhor a partir de um IP limpo de data center do que de uma saída residencial de baixa confiança. Portanto, forceProxy: false pode tornar certos alvos mais fáceis, e não mais difíceis. Se você estiver enfrentando desafios repetidos em um host específico, vale a pena tentar desativar essa opção.
ignoreProxies é uma lista de exclusão do cliente. Passe os IDs de proxy que você sabe que estão queimados (de um session.proxy anterior que sofreu rate limit do seu lado), e o Auto os ignora em todos os lugares: reutilização de sessão ativa, busca de saída e na subchamada para o Proxy Finder. Dessa forma, o Auto não escolherá novamente a saída que você acabou de pedir para evitar.
O meta também permite que você crie seus próprios dashboards: quais hosts atingiram o nível de navegador hoje, média de tentativas por entrega, proporção de requisições com desafios resolvidos em relação a requisições limpas. Se um host específico subir repentinamente de 2 para 10 créditos, esse é um sinal de degradação de sessão no qual você pode agir antes que sua fatura aumente.
Um exemplo que combina os quatro:
import requests
r = requests.post(
"https://api.foura.ai/api/auto",
headers={"X-API-Key": "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 o schema validate em si, consulte o passo a passo anterior em Validate Rules Now Decide What Counts as Success.
O que vem a seguir
Dois itens estão no roadmap do Auto no momento.
A inspeção de sessões chegará ao Dashboard em breve. Atualmente, as sessões que o Auto mantém por host ficam dentro do serviço, e não há nada para visualizar quando você está depurando um consumo inesperado do seu lado. Estamos desenvolvendo uma visualização de sessão por host para que você possa ver as sessões em cache, suas idades, quanto tempo ainda durarão e o histórico de rung por trás de cada uma. Além disso, haverá um botão para descartar uma sessão manualmente quando seu alvo mudar e você souber que o cache está desatualizado.
Depois disso, controles de custo mais rígidos. Um limite fixo de créditos por request (nunca gaste mais de X nesta chamada, falhe honestamente se isso acontecer) e um modo "single-only" para equipes cujos alvos nunca precisam do rung de browser. Ambos estão protegidos por flags hoje.
O objetivo do Auto é que você não precise pensar sobre qual produto chamar. Isso não significa que você não possa inspecionar o que aconteceu. Cada response inclui o rung utilizado e a sessão que ele criou. Leia esses dois campos e você saberá exatamente por que suas chamadas custaram o que custaram.