Novidades
O endpoint /api/auto agora é o caminho mais curto para uma response funcional para qualquer URL. Aponte-o para um alvo. O Auto escolhe se deve executar o request por Single, Proxy Finder ou Browser, lida com desafios anti-bot quando encontra um, e retorna uma sessão que sua próxima chamada pode reutilizar.
Um endpoint. Qualquer alvo. Nenhuma troca de modo do seu lado.
Essa é a ideia toda. O resto deste post mostra como funciona, quanto custa e onde estão os pontos críticos.
Como funciona
Por baixo do Auto existe uma escada de degraus (mais barato primeiro, mais caro por último). A cada request, o Auto sobe a escada até que um degrau entregue uma response que suas regras validate aceitem.
Os degraus, em ordem:
- Sessão em cache. Se o Auto tiver uma sessão quente para este host de uma chamada anterior, ele a repete primeiro. Caminho mais barato.
- Proxy Finder. Um request de proxy rotacionado. 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 que o site emite.
Quando um degrau vence, o Auto armazena a sessão que encontrou: o id do proxy que usou, os cookies que o site emitiu e o User-Agent. Na próxima chamada para o mesmo host, o Auto tenta essa sessão primeiro. Se ainda funcionar, você paga pelo degrau barato, não pelo caro.
Uma chamada mínima:
curl -X POST "https://api.foura.ai/api/auto" \
-H "Authorization: Bearer pk_live_..." \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/data",
"validate": { "status": { "accept": [200] } }
}'
Uma response 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ê construirá a seguir. meta.rung informa qual caminho venceu. session é a tripla que você pode levar para uma chamada /api/single para reproduzir a mesma saída você mesmo. O campo proxy é um ID opaco base36 (sem IPs puros), seguro para logar e seguro para passar entre sistemas.
Impacto
Dois números importam aqui.
A primeira chamada para um site protegido executa o degrau Browser: renderiza, resolve, coleta cookies, entrega a página a você. Isso custa cerca de 10 créditos. Uma vez que o Auto armazenou em cache uma sessão funcional para aquele host, as chamadas subsequentes passam pelo Single a 2 créditos. Assim, a segunda chamada é 5x mais barata que a primeira, e todas as seguintes continuam pagando a taxa mais barata enquanto a sessão se mantiver. Medimos isso em produção durante a implementação: saídas sem cookies (uma vez encontradas) reproduzem a exatamente 2 créditos por chamada, contra os 10 que costumavam custar quando todas as solicitações passavam pelo Proxy Finder.
O segundo número: degraus com falha não são faturados. Se o Auto tentar três proxies e cada um retornar 403 antes que o quarto entregue, apenas os créditos do quarto contam. Você paga pelo conteúdo entregue, não pela busca.
Esse é o valor principal. O degrau caro é executado uma vez, o degrau barato é executado para sempre depois disso, e você não precisa escrever a lógica de cache você mesmo.
Vale a pena destacar dois outros comportamentos porque eles resolvem verdadeiras dores de cabeça em produção:
Alvos com bloqueio geográfico param de desperdiçar saídas. Quando um site retorna 451 (ou um intersticial de bloqueio legal) para a maioria das saídas, o Auto aprende quais países realmente entregaram conteúdo. Na próxima chamada, ele puxa saídas novas desses países primeiro e distribui a carga concorrente entre elas. Portanto, uma única saída sortuda não fica sobrecarregada com rate limit.
Validate é executado em todos os degraus. Uma página com conteúdo errado (um bloqueio geográfico que retorna status 200 com um aviso legal no corpo) nunca conta como um acerto. Se o seu validate.data.fail disser "razões legais", o Auto continua tentando até que um degrau passe por ele. Nem o degrau em cache. Nem qualquer degrau. Se nada passar, você recebe uma falha honesta com o motivo real.
Para Power Users
Alguns controles que importam quando você passa muito volume pelo Auto.
timeout_ms é um orçamento para toda a operação, não um orçamento por degrau. O padrão é 120 segundos. O Auto o divide: cada subchamada recebe min(seu timeout natural, o orçamento restante), e a escada para de iniciar novos degraus assim que restar pouco tempo. Defina 20.000 para trabalho com latência interativa. Deixe o padrão para crawls em massa que toleram tempos mais longos.
forceProxy está ativado por padrão. O Auto nunca toca o alvo a partir do IP de origem da FourA, a menos que você defina forceProxy: false. Uma ressalva: alguns sites (Cloudflare interativo com IP-trust gating) na verdade funcionam melhor a partir de um IP de data center limpo do que de uma saída residencial de baixa confiança. Portanto, forceProxy: false pode tornar certos alvos mais fáceis, não mais difíceis. Se você estiver vendo desafios repetidos em um host específico, vale a pena tentar desativá-lo.
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 quente, busca de saída e a subchamada para o Proxy Finder. Assim, o Auto não escolherá novamente a saída que você acabou de dizer para evitar.
O meta também permite que você crie seus próprios dashboards por cima: quais hosts atingiram o nível do navegador hoje, média de tentativas por entrega, proporção de buscas com desafio resolvido em relação às limpas. Se um host específico subir repentinamente de 2 créditos para 10, isso é um sinal de degradação de sessão sobre o qual você pode agir antes que o custo chegue na sua conta.
Um exemplo que compõe os quatro:
import requests
r = requests.post(
"https://api.foura.ai/api/auto",
headers={"Authorization": "Bearer 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, veja o passo a passo anterior em Validate Rules Now Decide What Counts as Success.
O que vem a seguir
Duas coisas estão no roadmap para o Auto no momento.
A inspeção de sessões chegará ao Dashboard em seguida. No momento as sessões que o Auto mantém por host vivem dentro do serviço, e não há nada para olhar quando você está depurando um consumo do seu lado. Estamos montando uma visualização de sessão por host para que você possa ver as sessões em cache, suas idades, quanto tempo elas viverão e o histórico de rung por trás de cada uma. Além de um botão para descartar uma sessão manualmente quando seu alvo mudar e você souber que o cache está errado.
Depois disso, controles de custos mais rigorosos. Um limite de créditos fixo por request (nunca gaste mais de X nesta chamada, falhe honestamente se for o caso) e um modo "apenas single" para equipes cujos alvos nunca precisam do rung de navegador. Ambos estão atrás de flags hoje.
O objetivo do Auto é que você não precise pensar em qual produto chamar. Isso não significa que você não possa inspecionar o que aconteceu. Cada response envia o rung que utilizou e a sessão que construiu. Leia esses dois campos e você saberá exatamente por que suas chamadas custaram o que custaram.