Сверка использования CAPTCHA с балансом рабочего пространства

Запросы API проходят аутентификацию с помощью API-ключа рабочего пространства. При сверке использования проверяйте именно это рабочее пространство; одинаковое имя хоста целевого сайта не означает, что запросы относятся к одному рабочему пространству.

Страница использования /usage помечена как последние 28 дней. На ней отображаются Request volume, Successful, Failed (not billed), Average latency и либо Period spend, либо Unlimited coverage. Не делайте выводов о соответствующем счёте или текущем балансе только на основании этого периода.

Используйте By site profile, чтобы найти всплеск. Сравните Site, Share и Requests, чтобы определить, где вырос объём, затем изучите Success и Billing. Это события использования сервиса, а не доказательство того, что целевой сайт принял полученные запросы.

Задача со статусом ready оплачивается. За неудачное решение средства возвращаются. Создание задачи или получение успешного HTTP-ответа не равнозначно получению пригодного решения; оно содержится только в ready.

Если сервис решения возвращает готовое решение, но сайт отклоняет последующий запрос, это не означает, что задача сервиса завершилась с ошибкой. Не учитывайте её в Failed (not billed) и не рассчитывайте на автоматический возврат средств. Задача, созданная взамен и достигшая ready, — ещё одно оплачиваемое решение.

Минимальная сумма пополнения — $10; приветственный баланс — $5. Пополнение добавляет средства на баланс рабочего пространства, а не показывает, сколько было потрачено за период использования. Сравнивая платежи с балансом, учитывайте отдельно купленные средства и приветственный баланс.

Для оценки затрат с оплатой по факту использования учитывайте оплачиваемые задачи со статусом ready, а не общее число запросов. Если в консоли отображается Unlimited coverage, проверьте соответствующий месячный тариф для конкретного продукта вместо того, чтобы рассчитывать стоимость всех запросов по факту использования. Средства на счёте или применимый бонус также могут повлиять на сумму необходимого пополнения.

1. 1.

   Сопоставьте сайт и временной интервал

   Сузьте поиск с помощью разбивки по профилям сайтов, затем сравните журналы приложения за тот же период. Зафиксируйте логический запрос, его requestId, возвращённый ID задачи и конечный статус.

2. 2.

   Проверьте, не обслуживают ли несколько задач один запрос

   Несколько разных ID задач для одного запланированного решения могут объяснить дополнительные списания, если эти задачи достигли статуса ready. Отделяйте намеренное получение новых решений взамен прежних от повторных попыток из-за потери ответа.

3. 3.

   Восстановите результат запросов создания, завершившихся тайм-аутом

   Тайм-аут соединения не доказывает, что задача не была создана. Если у вас есть ID задачи, получите её. В противном случае повторите тот же запрос задачи с исходным requestId, чтобы получить существующую задачу, а не создавать новую логическую задачу.

4. 4.

   Назначайте requestId до первой попытки

   Используйте один requestId для каждого запланированного решения и сохраняйте его при повторных попытках. Он допускает 1–64 ASCII-буквы, цифры, знаки подчёркивания или дефисы. Тот же ID с тем же запросом задачи возвращает существующую задачу; его использование с другими входными данными вызывает конфликт.

При расследовании дублирующего создания считайте отдельные задачи, а не только HTTP-попытки. Несколько повторных попыток, возвращающих один и тот же ID задачи, не создают несколько задач.