Перенесите интеграцию reCAPTCHA с CapSolver на solvethree

solvethree по умолчанию использует reCAPTCHA v3 Enterprise и также поддерживает стандартную v3. Другие его публичные продукты — Kasada и Ticketmaster TMPT. Он не поддерживает reCAPTCHA v2, hCaptcha, Turnstile и решение через расширение браузера, поэтому не является универсальной заменой для любой интеграции CapSolver.

Перед отправкой задачи reCAPTCHA настройте целевой сайт в консоли и убедитесь, что вашему рабочему пространству доступен активный профиль. Передача имени хоста и действия не создаёт этот профиль. Не удаляйте поле websiteKey CapSolver в расчёте на то, что оставшегося запроса будет достаточно.

Исходный запрос использует clientKey CapSolver и обёртку задачи, специфичную для провайдера:

{
  "clientKey": "CAPSOLVER_API_KEY",
  "task": {
    "type": "ReCaptchaV3Task",
    "websiteURL": "https://accounts.example.com/login",
    "websiteKey": "PUBLIC_SITE_KEY",
    "pageAction": "login",
    "isEnterprise": true,
    "proxy": "http://user:[email protected]:8080"
  }
}

Для solvethree отправьте приведённое ниже плоское тело на POST https://api.solvethree.com/v1/tasks. Установите заголовок Authorization в значение Bearer, за которым следует API-ключ вашего рабочего пространства. Храните этот ключ на сервере; не переносите clientKey в новое тело JSON.

{
  "site": "accounts.example.com",
  "action": "login",
  "proxy": "http://user:[email protected]:8080",
  "requestId": "example_login_001"
}

В примере используется запрос Enterprise, поскольку для recaptchaType оставлено значение по умолчанию. Если целевой сайт использует стандартную v3, выберите её явно; не сопоставляйте каждый тип задачи CapSolver со значением Enterprise по умолчанию.

У задачи CapSolver ProxyLess здесь нет прямого аналога без прокси: solvethree требует, чтобы вызывающая сторона предоставила прокси. Если ваша текущая интеграция не управляет прокси, потребуется изменить интеграцию, а не просто переименовать поле. Не копируйте в новый запрос и настройки SOCKS-прокси; solvethree принимает URL HTTP- и HTTPS-прокси.

Начните с одного прокси, чтобы маршрут решения и отправки был однозначным. Если вместо этого используется proxyCandidates, укажите не более двенадцати различных URL HTTP- или HTTPS-прокси без путей, строк запроса и фрагментов. Кандидаты позволяют сервису пробовать альтернативные точки выхода; они не гарантируют, что прокси или целевой сайт будут работать.

CapSolver получает асинхронные результаты через getTaskResult с clientKey и taskId. solvethree получает их через GET /v1/tasks/:id с Bearer-аутентификацией. Обновите не только HTTP-вызов, но и разбор результата; поля статуса и ошибки CapSolver относятся к другому контракту API.

1. 1.

   Сначала проверьте HTTP-ответ

   Обрабатывайте неуспешные HTTP-ответы до чтения данных успешного ответа. Ошибка HTTP-запроса и неудачное решение задачи требуют отдельной обработки.

2. 2.

   Проверьте задачу, возвращённую при создании

   При создании задачи reCAPTCHA ожидание по умолчанию составляет до 15 секунд, поэтому ответ уже может содержать конечный статус. Только ready содержит пригодное к использованию решение. Если задача имеет статус pending или solving, запросите её по возвращённому ID задачи solvethree.

3. 3.

   Остановите опрос при ready или failed

   При ready передайте решение коду отправки. При failed проверьте errorCode и error и прекратите опрос этой задачи. Стоимость неудачных решений возвращается. Не повторяйте вслепую запросы с неизменёнными некорректными данными и не считайте, что любая ошибка означает недостаток средств.

При поэтапном переходе сохраняйте для каждого ID задачи пометку о провайдере. Завершайте существующие задачи CapSolver через CapSolver, а новые задачи solvethree направляйте через solvethree. Приводите их результаты к единому виду в адаптере, а не отправляйте ID задачи прежнего провайдера в новый API.

Используйте solution.token при отправке результата reCAPTCHA на нужный целевой сайт. Также сохраняйте возвращённые userAgent и secChUa и используйте для отправки прокси, через который удалось решить задачу. Если существующий адаптер возвращает только строку токена, измените его так, чтобы эта информация доходила до отправляющего клиента.

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

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

Если при создании истёк тайм-аут, запросите задачу, если у вас есть её ID, или повторно отправьте то же тело с тем же requestId. Потерянный ответ не доказывает, что создание не удалось. Не создавайте новый ID лишь потому, что клиент перестал ждать.

В тайм-ауте клиента учитывайте стандартное ожидание создания reCAPTCHA до 15 секунд и сетевые задержки. По умолчанию GET-опрос возвращает ответ без ожидания и принимает waitMs до 15000. Помещайте waitMs в строку запроса URL, а не в JSON задачи, и учитывайте это ожидание также в тайм-ауте опроса.