Concilie o uso de CAPTCHA com o saldo do seu espaço de trabalho

As requisições à API são autenticadas com uma chave de API do espaço de trabalho. Verifique esse espaço de trabalho ao conciliar o uso; um hostname de destino compartilhado não significa que as requisições pertencem ao mesmo espaço de trabalho.

O uso em /usage é identificado como últimos 28 dias. Ele mostra Request volume, Successful, Failed (not billed), Average latency e Period spend ou Unlimited coverage. Não deduza uma fatura correspondente nem o saldo de crédito atual apenas com base nessa janela.

Use By site profile para localizar um pico. Compare Site, Share e Requests para descobrir onde o volume aumentou e inspecione Success e Billing. Esses são eventos de uso do serviço, não evidências de que o destino aceitou as requisições resultantes.

Uma tarefa com status ready é cobrada. Uma resolução com falha é reembolsada. Criar uma tarefa ou receber uma resposta HTTP de sucesso não é o mesmo que receber uma solução utilizável; apenas ready contém uma.

Se o serviço de resolução retornar uma solução pronta, mas o site rejeitar a requisição subsequente, isso não é uma falha de tarefa do serviço de resolução. Não a contabilize em Failed (not billed) nem presuma que ela recebe um reembolso automático. Uma tarefa substituta que chega a ready é outra resolução cobrada.

O depósito mínimo de crédito é de $10; o crédito de boas-vindas é de $5. Um depósito adiciona crédito ao espaço de trabalho — ele não indica quanto foi gasto no período de uso. Mantenha o crédito comprado e o crédito de boas-vindas separados ao comparar seus pagamentos com o saldo.

Use as tarefas prontas cobradas — não o volume total de requisições — para estimar o custo por uso. Se o console mostrar Unlimited coverage, consulte o plano mensal específico do produto aplicável em vez de calcular o preço de todas as requisições por uso. O crédito da conta ou um bônus aplicável também pode alterar quanto crédito adicional você precisa.

1. 1.

   Identifique o site afetado e o período correspondente

   Use o detalhamento por perfil de site para restringir a busca e compare os logs da sua aplicação no mesmo período. Registre a requisição lógica, seu requestId, o ID da tarefa retornado e o status final.

2. 2.

   Procure várias tarefas atendendo a uma única requisição

   Vários IDs de tarefa distintos para uma única resolução pretendida podem explicar cobranças extras se essas tarefas chegarem ao status ready. Separe as resoluções de substituição intencionais das novas tentativas feitas porque uma resposta foi perdida.

3. 3.

   Recupere requisições de criação que excederam o tempo limite

   Um tempo limite de conexão não comprova que a criação da tarefa falhou. Se você tiver o ID da tarefa, consulte essa tarefa. Caso contrário, repita a mesma requisição de tarefa com o requestId original para recuperar a tarefa existente em vez de criar uma nova tarefa lógica.

4. 4.

   Defina requestId antes da primeira tentativa

   Use um requestId por resolução pretendida e mantenha-o nas novas tentativas. Ele aceita de 1–64 letras ASCII, números, sublinhados ou hífens. O mesmo ID com a mesma requisição de tarefa retorna a tarefa existente; usá-lo com entradas diferentes gera conflito.

Conte tarefas distintas ao investigar criação duplicada, não apenas tentativas HTTP. Várias tentativas que retornam o mesmo ID de tarefa não criaram várias tarefas.