← Все статьи

Представляем Auto: один endpoint для любой цели

Endpoint Auto выбирает Single, Proxy Finder или Browser для каждого request, обрабатывает страницы с проверками клиента и возвращает session для повторного использования в следующем вызове.

Что нового

Endpoint /api/auto теперь самый короткий путь к рабочему response для любого URL. Укажите целевой адрес. Auto сам выбирает, как выполнить request: через Single, Proxy Finder или Browser, проходит проверки страницы при их появлении и возвращает session, которую можно переиспользовать в следующем вызове.

Один endpoint. Любая цель. Никаких переключений режимов с вашей стороны.

В этом вся суть. Далее в статье: как это устроено, сколько стоит и какие есть нюансы.

Как это работает

В основе Auto лежит ступенчатая схема (от дешевых к дорогим). При каждом request Auto идет по ступеням вверх, пока одна из них не вернет response, подходящий под ваши правила validate.

Ступени по порядку:

  1. Кэшированная session. Если у Auto есть готовая session для этого хоста от прошлого вызова, сначала запрос идет через нее. Самый дешевый путь.
  2. Proxy Finder. Request через ротируемый proxy. Подходит для сайтов с защитой в основном по репутации IP.
  3. Browser. Полный рендеринг: выполняет JavaScript, проходит проверки страницы и собирает выданные сайтом cookie.

Когда ступень сработала, Auto сохраняет найденную session: использованный proxy id, выданные сайтом cookie и User-Agent. При следующем вызове к этому же хосту Auto сначала пробует эту session. Если она все еще работает, вы платите по тарифу дешевой ступени, а не дорогой.

Минимальный вызов:

curl -X POST "https://api.foura.ai/api/auto" \
  -H "X-API-Key: pk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/data",
    "validate": { "status": { "accept": [200] } }
  }'

Сокращенный response:

{
  "status": 200,
  "data": "...",
  "headers": [...],
  "meta": {
    "rung": "cache",
    "solved": false,
    "attempts": 1,
    "credits": 2
  },
  "session": {
    "proxy": "CLN1B8",
    "cookies": [{ "name": "cf_clearance", "value": "..." }],
    "userAgent": "..."
  }
}

Два поля имеют значение для дальнейшей интеграции. meta.rung показывает, какой путь сработал. session представляет собой тройку значений, которую можно передать в вызов /api/single, чтобы повторить тот же exit самостоятельно. Поле proxy это непрозрачный идентификатор в base36 (без открытых IP), безопасный для логирования и передачи между системами.

Результаты

Здесь важны две цифры.

Первый вызов к защищенному сайту запускает уровень Browser: рендеринг, прохождение проверок, сбор cookies и возврат страницы. Это стоит около 10 кредитов. Как только Auto кэширует рабочую сессию для этого хоста, последующие вызовы воспроизводят ее: через Single за 2 кредита или через Proxy Finder за 4 кредита, когда cookies сессии работают с любого адреса. Таким образом, второй вызов обходится до 5 раз дешевле первого, и каждый последующий тарифицируется по низкому тарифу, пока жива сессия. Мы замерили это в проде при запуске: выходы без cookies (после обнаружения) повторяются ровно по 2 кредита за вызов вместо прежних 10, когда каждый request шел через Proxy Finder.

Вторая цифра: неудачные попытки не тарифицируются. Если Auto пробует три proxy и каждый возвращает 403 до того, как четвертый отдает контент, списываются кредиты только за четвертый. Вы платите за доставленный контент, а не за поиск.

В этом основная ценность. Дорогой уровень запускается один раз, дешевый работает все последующее время, и вам не нужно писать логику кэширования самостоятельно.

Стоит отметить еще два сценария поведения, так как они решают реальные проблемы в проде:

Геоблокировки больше не сжигают рабочие выходы впустую. Когда сайт возвращает 451 (или страницу с юридической заглушкой) для большинства выходов, Auto запоминает страны, которые действительно отдали контент. При следующем вызове сервис в первую очередь берет свежие выходы из этих стран и распределяет параллельную нагрузку между ними. В результате один удачный выход не перегружается запросами и не попадает под rate limit.

Validate работает на каждом уровне. Страница с некорректным содержимым (например, региональное ограничение со статусом 200 и уведомлением о блокировке в теле ответа) никогда не считается успешной. Если ваш validate.data.fail содержит "legal reasons", Auto продолжает перебор, пока один из уровней не пройдет проверку. Ни кэшированный уровень, ни какой-либо другой не сработает вслепую. Если ни один вариант не подошел, вы получите честную ошибку с реальной причиной.

Для продвинутых пользователей

Несколько параметров, которые важны при больших объемах через Auto.

timeout_ms задает общий бюджет времени на всю операцию, а не на отдельный уровень. По умолчанию это 120 секунд. Auto распределяет его: каждый подзапрос получает min(свой стандартный timeout, оставшийся бюджет), и цепочка перестает запускать новые уровни, если времени осталось слишком мало. Установите 20 000 для задач с интерактивной задержкой. Оставьте значение по умолчанию для массового сбора данных, где допустимы долгие задержки на хвосте распределения.

forceProxy включен по умолчанию. Auto никогда не обращается к целевому ресурсу с исходного IP сервиса FourA, если не указан параметр forceProxy: false. Одно замечание: некоторые сайты (интерактивный Cloudflare с проверкой доверия к IP) работают лучше с чистого IP дата-центра, чем с резидентного выхода с низким уровнем доверия. Поэтому forceProxy: false может упростить доступ к определенным целям, а не усложнить его. Если вы сталкиваетесь с постоянными проверками на конкретном хосте, имеет смысл попробовать отключить эту опцию.

ignoreProxies представляет собой клиентский avoid-list. Передавайте proxy id, которые уже скомпрометированы (из предыдущего session.proxy, где сработал rate limit на вашей стороне), и Auto пропустит их на всех этапах: при повторном использовании горячих сессий, поиске выходных узлов и во вложенном вызове Proxy Finder. Таким образом Auto не выберет повторно выходной узел, который вы указали исключить.

meta также позволяет строить собственные дашборды: какие хосты сегодня перешли на уровень браузера, среднее количество попыток на доставку, соотношение запросов с решением челленджей к чистым запросам. Если конкретный хост внезапно вырастает с 2 кредитов до 10, это сигнал деградации сессии, на который можно отреагировать до того, как вырастут расходы.

Пример, объединяющий все четыре компонента:

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"X-API-Key": "pk_live_..."},
    json={
        "url": "https://example.com/product/9876",
        "timeout_ms": 30000,
        "forceProxy": True,
        "ignoreProxies": ["CLN1B8", "K7X9AB"],
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ['"price":'], "fail": ["captcha", "legal reasons"]}
        }
    }
).json()

# If Auto delivered, keep the session for the next call to this host
if r.get("status") == 200 and "session" in r:
    session = r["session"]                              # {proxy, cookies, userAgent}
    print(r["meta"]["rung"], r["meta"]["credits"], r["meta"]["attempts"])

О самой схеме validate читайте в предыдущем разборе Validate Rules Now Decide What Counts as Success.

Что дальше

Сейчас в роадмапе для Auto две вещи.

Скоро в Dashboard появится инспекция сессий. Сейчас сессии, которые Auto держит для каждого хоста, живут внутри сервиса, и при отладке расхода с вашей стороны посмотреть не на что. Мы подключаем интерфейс сессий по хостам, чтобы вы могли видеть кэшированные сессии, их возраст, оставшееся время жизни и историю шагов для каждой. Плюс кнопку для ручного сброса сессии, когда цель изменилась и вы точно знаете, что кэш невалиден.

После этого добавим более строгий контроль расходов. Жесткий лимит кредитов на request (никогда не тратить больше X на этот вызов, честно возвращать ошибку при превышении) и режим "single-only" для команд, чьим целям никогда не требуется браузерный уровень. Сейчас обе функции находятся за флагами.

Смысл Auto в том, чтобы не думать о выборе конкретного продукта. Но это не значит, что вы не можете проверить, что произошло. Каждый response возвращает использованный уровень и созданную сессию. Проверьте эти два поля, и вы будете точно знать, почему вызовы стоят именно столько.