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

> URL: https://foura.ai/ru/blog/auto-endpoint
> Updated: 2026-09-27
> Index: https://foura.ai/llms.txt

## Что нового

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. Если она все еще работает, вы платите по тарифу дешевой ступени, а не дорогой.

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

```bash
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:

```json
{
  "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, это сигнал деградации сессии, на который можно отреагировать до того, как вырастут расходы.

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

```python
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](https://foura.ai/blog/validate-decides-success).

## Что дальше

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

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

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

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