Concilia el uso de CAPTCHA con el saldo de tu espacio de trabajo

Las solicitudes a la API se autentican con una clave de API del espacio de trabajo. Comprueba ese espacio de trabajo al conciliar el uso; compartir un nombre de host de destino no significa que las solicitudes pertenezcan al mismo espacio de trabajo.

El uso en /usage lleva la etiqueta últimos 28 días. Muestra Request volume, Successful, Failed (not billed), Average latency y, según corresponda, Period spend o Unlimited coverage. No deduzcas una factura correspondiente ni el saldo de crédito actual solo a partir de ese intervalo.

Usa By site profile para localizar un pico. Compara Site, Share y Requests para averiguar dónde aumentó el volumen y después examina Success y Billing. Son eventos de uso del servicio, no pruebas de que el destino aceptara las solicitudes resultantes.

Una tarea con estado ready se factura. Una resolución fallida se reembolsa. Crear una tarea o recibir una respuesta HTTP de éxito no equivale a recibir una solución utilizable; solo ready contiene una.

Si el servicio de resolución devuelve una solución lista, pero el sitio web rechaza la solicitud posterior, eso no constituye un fallo de la tarea de resolución. No lo contabilices en Failed (not billed) ni supongas que recibe un reembolso automático. Una tarea de sustitución que alcanza ready es otra resolución facturada.

El depósito mínimo de crédito es de $10; el crédito de bienvenida es de $5. Un depósito añade crédito al espacio de trabajo; no indica cuánto se gastó durante el período de uso. Mantén separados el crédito comprado y el crédito de bienvenida al comparar tus pagos con el saldo.

Usa las tareas facturadas en estado ready, no el volumen total de solicitudes, para estimar el coste de pago por uso. Si la consola muestra Unlimited coverage, consulta el plan mensual específico del producto que corresponda en lugar de calcular el precio de todas las solicitudes como pago por uso. El crédito de la cuenta o una bonificación aplicable también pueden cambiar cuánto crédito adicional necesitas.

1. 1.

   Identifica el sitio y el período afectados

   Usa el desglose por perfil de sitio para acotar la búsqueda y compara los registros de tu aplicación durante el mismo período. Registra la solicitud lógica, su requestId, el ID de tarea devuelto y el estado final.

2. 2.

   Busca varias tareas para una misma solicitud

   Varios ID de tarea distintos para una única resolución prevista pueden explicar los cargos adicionales si esas tareas llegan al estado ready. Distingue las resoluciones de reemplazo deliberadas de los reintentos realizados porque se perdió una respuesta.

3. 3.

   Recupera las solicitudes de creación cuyo tiempo de espera se agotó

   Que se agote el tiempo de espera de una conexión no demuestra que la creación de la tarea haya fallado. Si tienes el ID de tarea, recupera esa tarea. De lo contrario, reintenta la misma solicitud de tarea con su requestId original para recuperar la tarea existente en lugar de crear una nueva tarea lógica.

4. 4.

   Asigna requestId antes del primer intento

   Usa un requestId por cada resolución prevista y consérvalo en los reintentos. Acepta entre 1 y 64 letras ASCII, números, guiones bajos o guiones. El mismo ID con la misma solicitud de tarea devuelve la tarea existente; usarlo con entradas distintas genera un conflicto.

Cuenta las tareas distintas al investigar creaciones duplicadas, no solo los intentos HTTP. Varios reintentos que devuelven el mismo ID de tarea no han creado varias tareas.