O que há de novo
O endpoint /api/auto é agora o caminho mais curto para obter uma response funcional para qualquer URL. Aponte-o para um alvo. O Auto escolhe se executa o request via Single, Proxy Finder ou Browser, resolve a verificação da página quando encontra uma e retorna 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 explica como funciona, quanto custa e onde estão os pontos de atenção.
Como funciona
Abaixo do Auto há uma sequência de etapas (a mais barata primeiro, a mais cara por último). A cada request, o Auto sobe essas etapas até que uma entregue uma response aceita pelas suas regras validate.
As etapas, em ordem:
- Session em cache. Se o Auto tiver uma session ativa para este host de uma chamada anterior, ele a reutiliza primeiro. O caminho mais barato.
- Proxy Finder. Um request com proxy rotativo. Ideal para sites protegidos principalmente por reputação de IP.
- Browser. Uma renderização completa que executa JavaScript, conclui as verificações exigidas pela página 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 mais 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 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ê 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 transferir entre sistemas.
Impacto
Dois números importam aqui.
A primeira chamada para um site protegido executa a etapa Browser: renderiza, resolve, coleta cookies e entrega a página para você. Isso custa cerca de 10 créditos. Assim 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 chamada subsequente continua pagando a taxa reduzida enquanto a sessão durar. Medimos isso em produção durante o lançamento: saídas sem cookies (uma vez encontradas) são reproduzidas a exatamente 2 créditos por chamada, contra os 10 que costumavam custar quando cada request passava pelo Proxy Finder.
O segundo número: etapas que falham não são cobradas. Se o Auto tentar três proxies e cada um retornar 403 antes que o quarto entregue o conteúdo, apenas os créditos do quarto contam. Você paga pelo conteúdo entregue, não pela busca.
Esse é o valor principal. A etapa cara roda uma vez, a etapa barata roda para sempre depois, e você não precisa escrever a lógica de cache por conta própria.
Outros dois comportamentos valem o destaque porque resolvem dores de cabeça reais em produção:
Alvos com restrição geográfica não desperdiçam 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 o conteúdo. Na chamada seguinte, ele busca novas saídas desses países primeiro e distribui a carga concorrente entre elas. Assim, uma única saída que funcionou não fica sobrecarregada sofrendo rate limit.
Validate executa em cada etapa. Uma página com conteúdo incorreto (uma restrição de país que retorna status 200 com um aviso legal no body) nunca conta como sucesso. Se o seu validate.data.fail contiver "legal reasons", o Auto continua tentando até que uma etapa seja aprovada. Não a etapa em cache. Nenhuma etapa intermediária. 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 limite de tempo para a operação inteira, não por etapa. O padrão é 120 segundos. O Auto o divide: cada subchamada recebe min(seu timeout natural, o tempo restante), e a sequência para de iniciar novas etapas assim que resta pouco tempo. Defina 20.000 para operações de latência interativa. Deixe o padrão para coletas em lote que toleram tempos maiores.
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 vendo desafios repetidos em um host específico, vale a pena testar desativar isso.
ignoreProxies é uma avoid-list do cliente. Passe IDs de proxy que você sabe que foram queimados (de um session.proxy anterior que sofreu rate limit do seu lado), e o Auto os ignora em todos os lugares: reúso de warm session, busca de saída e na subchamada para o Proxy Finder. Assim, o Auto não escolherá novamente a saída que você acabou de instruir para evitar.
meta também permite que você crie seus próprios dashboards por cima: quais hosts atingiram o nível de navegador hoje, média de tentativas por entrega, proporção de coletas com desafios resolvidos em relação às limpas. Se um host específico subir repentinamente de 2 créditos para 10, esse é um sinal de degradação de sessão no qual você pode agir antes que sua fatura aumente.
Um exemplo que compõe todos 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 seguida. Atualmente, as sessões que o Auto mantém por host ficam dentro do serviço, e não há nada para analisar quando você está depurando um gasto do seu lado. Estamos criando uma visualização de sessão por host para que você possa ver as sessões em cache, a idade delas, quanto tempo vão durar e o histórico de etapas por trás de cada uma. Além disso, adicionaremos um botão para descartar uma sessão manualmente quando o seu alvo mudar e você souber que o cache está incorreto.
Depois disso, controles de custo mais rigorosos. Um limite rígido de créditos por request (nunca gaste mais de X nesta chamada, falhe honestamente se fosse o caso) e um modo "single-only" para equipes cujos alvos nunca precisam da etapa 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 a etapa utilizada e a sessão que foi criada. Leia esses dois campos e você saberá exatamente por que suas chamadas custam o que custam.