Resultados de Requests

Cada request para a API FourA é classificado em exatamente um outcome, e o mesmo vale para cada túnel pela porta de proxy. O outcome é calculado uma vez, ao final da chamada, e registrado na credencial que o originou. Seu painel, feed de atividades e faturamento leem todos o mesmo campo.

Apenas success consome créditos. O tráfego premium é contabilizado separadamente dos créditos e não segue o outcome: consulte Billing Implications.

The Seven Outcomes

Estes são os sete estados em que um request pode terminar. Um túnel usa cinco deles: consulte Tunnels Use the Same Vocabulary abaixo.

A coluna de layer indica o responsável:

• Outcomes target dizem respeito ao site chamado. Seu request chegou perfeitamente ao FourA, e o FourA alcançou o destino perfeitamente. O próprio destino retornou um erro.
• Outcomes caller significam que seu request não pôde ser processado. Corrija o formato do request.
• Outcomes FourA são de nossa responsabilidade. Tente novamente e verifique a página de status se persistirem.

Um site de destino que retorna 403 é application_fail, não client_error. Sua chamada estava bem formatada. O site apenas recusou.

Success Is validate-Aware

Sem validate, a API marca um request como success apenas quando o destino retorna HTTP 200.

Com validate, o sucesso segue as regras que você declarou. Se você informar à API que 200 e 403 são ambos aceitáveis para um determinado request, um 403 retorna como success. O corpo ainda chega até você inalterado.

curl -X POST https://eu.api.foura.ai/api/single/ \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "method": "GET",
    "url": "https://target.example/feed",
    "validate": {
      "status": { "accept": [200, 403] }
    }
  }'

Nesta chamada, uma resposta 403 conta como success e é cobrada como uma request. Uma resposta 500 conta como application_fail e não é cobrada.

A mesma lógica se aplica a validate.headers e validate.data. Qualquer resposta que o motor aceitar segundo as suas regras retorna como success, independentemente do status HTTP.

Uma resposta nunca é success, com ou sem validate: um HTTP 200 cujo corpo seja uma página de verificação de bot reconhecida pelo FourA, como uma tarefa de verificação visual ou uma página que apenas solicita que o navegador execute JavaScript. Essa request é application_error e não é cobrada. O corpo ainda chega até você sem alterações, e o header X-FourA-Check-Page identifica a página de verificação.

Implicações de Faturamento

Apenas as requests que entregaram os dados solicitados são cobradas. Falhas no lado do FourA, no lado do destino ou no seu próprio lado são todas gratuitas.

A tabela refere-se a créditos. O tráfego premium é contabilizado separadamente: uma request que tentou uma saída premium contabiliza o tráfego que essa tentativa transportou, independentemente do resultado, pois a saída foi utilizada de qualquer forma. Uma tentativa que ainda estava em execução quando outra saída respondeu é interrompida imediatamente, e o tráfego transportado até então também é contabilizado.

O tráfego padrão também não segue o resultado: em um plano com limite de largura de banda, o tráfego de cada request conta para esse limite. Uma request recusada por um dos limites do seu próprio plano não contabiliza tráfego.

Túneis Usam o Mesmo Vocabulário

Um túnel através da porta de proxy também termina em um desses resultados, de modo que um único conjunto de rótulos abrange ambos os produtos. Apenas cinco dos sete podem ocorrer, pois os dois resultados target exigem que o FourA tenha visto a resposta do destino, e a resposta de um túnel é o seu próprio tráfego criptografado.

Uma recusa também traz um motivo curto, e o dashboard o exibe nos seus próprios termos em vez dos nossos. Uma opção que a FourA não pode atender é respondida com 400 na própria conexão e não grava nenhuma linha, portanto nunca aparece aqui.

Nada em relação a um túnel é cobrado em créditos, porque um túnel não possui uma request para cobrar. A porta faz a medição por bytes. Consulte Como seu plano é medido.

Como ler os resultados no Dashboard

Cada request que sua chave de API faz aparece no feed Activity com o rótulo do seu resultado. As páginas Metrics e Overview agregam o mesmo campo para gráficos de rosca e cronogramas.

Quando você filtra Activity por resultado, também pode focar em um único endpoint (Auto, Single, Proxy Finder, Browser) para verificar se uma classe de falha é específica de um deles. Altere Product da página para Proxy e as mesmas tags de resultado filtrarão seus túneis.

Heurísticas de repetição

Uma política inicial de retry baseada nos resultados:

Relacionado

• Erros de API: respostas de erro no nível HTTP
• Porta do Proxy: status codes retornados na recusa de um túnel
• Rate Limits: o que dispara rate_limit e os dois formatos de retorno
• Métricas: onde você vê o detalhamento dos resultados
• Log de Atividade: histórico de resultados por request