# Представяме Auto: Един endpoint за всяка цел

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

## Какво ново

`/api/auto` endpoint вече е най-краткият път до работещ response за всеки URL. Насочете го към целта. Auto избира дали да изпълни заявката през Single, Proxy Finder или Browser, обработва проверките на страницата, ако срещне такива, и връща сесия, която следващото ви извикване може да използва повторно.

Един endpoint. Всяка цел. Без превключване на режими от ваша страна.

Това е цялата идея. Останалата част от тази публикация описва как работи, колко струва и кои са трудните моменти.

## Как работи

Под Auto стои стълбица от нива (първо евтините, накрая скъпите). При всяка заявка Auto се изкачва по стълбицата, докато някое ниво не върне response, който вашите `validate` правила приемат.

Нивата по ред:

1. **Кеширана сесия.** Ако Auto има готова сесия за този хост от предишно извикване, първо повтаря през нея. Най-евтиният път.
2. **Proxy Finder.** Заявка през ротирано proxy. Подходящо за сайтове, защитени основно по IP репутация.
3. **Browser.** Пълно рендиране, което изпълнява JavaScript, преминава проверките на страницата и събира върнатите от сайта cookies.

След като дадено ниво сработи успешно, Auto запазва намерената сесия: използваното proxy id, издадените от сайта cookies и User-Agent. При следващото извикване към същия хост Auto опитва първо тази сесия. Ако тя все още работи, плащате за евтиното ниво, а не за скъпото.

Минимално извикване:

```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`, за да възпроизведете същия изход сами. Полето `proxy` е непрозрачен base36 идентификатор (без сурови IP адреси), безопасен за логване и за предаване между системи.

## Ефект

Тук две числа имат значение.

Първото извикване към защитен сайт изпълнява нивото Browser: рендерира, решава, събира бисквитки и ви връща страницата. Това струва около 10 кредита. След като Auto кешира работеща сесия за този хост, последващите извиквания я възпроизвеждат: през Single на цена 2 кредита или през Proxy Finder на цена 4, когато бисквитките на сесията работят от всеки адрес. Така второто извикване е до 5 пъти по-евтино от първото, а всяко следващо запазва ниската цена, докато сесията е активна. Измерихме това в production среда по време на внедряването: изходите без бисквитки (след като бъдат открити) се възпроизвеждат на точно 2 кредита за извикване спрямо 10-те, които струваха преди, когато всяка заявка минаваше през Proxy Finder.

Второто число: неуспешните нива не се таксуват. Ако Auto опита три проксита и всяко върне статус 403, преди четвъртото да достави съдържанието, се начисляват само кредитите за четвъртото. Плащате за доставено съдържание, а не за търсенето.

Това е основната стойност. Скъпото ниво се изпълнява веднъж, евтиното ниво работи постоянно след това, а вие няма нужда да пишете логиката за кеширане сами.

Още две поведения заслужават внимание, защото решават реални production проблеми:

**Гео-ограничените цели спират да хабят изходи.** Когато даден сайт връща статус 451 (или междинна страница за правно блокиране) за повечето изходи, Auto научава кои държави реално са доставили съдържание. При следващото извикване той първо извлича нови изходи от тези държави и разпределя паралелното натоварване между тях. Така един късметлийски изход не бива претоварен и ограничен по брой заявки.

**Валидацията се изпълнява на всяко ниво.** Страница с грешно съдържание (ограничение по държава, което връща статус 200 с правно известие в тялото) никога не се зачита като попадение. Ако вашето `validate.data.fail` съдържа "legal reasons", Auto продължава да опитва, докато някое ниво не го премине успешно. Нито кешираното ниво. Нито което и да е ниво. Ако нищо не премине успешно, получавате честна грешка с реалната причина.

## За напреднали потребители

Няколко настройки, които имат значение, след като пуснете сериозен обем през Auto.

`timeout_ms` е бюджет за цялата операция, а не за отделно ниво. Стойността по подразбиране е 120 секунди. Auto го разпределя: всяко подизвикване получава min(естествения си таймаут, оставащия бюджет), а веригата спира да стартира нови нива, щом остане твърде малко време. Задайте 20 000 за задачи с интерактивна латентност. Оставете стойността по подразбиране за масово обхождане, което толерира по-дълги забавяния.

`forceProxy` е включено по подразбиране. Auto никога не осъществява достъп до целта от началния IP адрес на FourA, освен ако не зададете `forceProxy: false`. Едно уточнение: някои сайтове (интерактивен Cloudflare с филтриране по надеждност на IP адреса) всъщност работят по-добре от чист IP адрес на център за данни, отколкото от жилищен изход с ниско доверие. Затова `forceProxy: false` може да направи определени цели по-достъпни, а не по-трудни. Ако наблюдавате повтарящи се проверки на конкретен хост, си струва да опитате да изключите това.

`ignoreProxies` е клиентски avoid-list. Подайте proxy ID-та, за които знаете, че са изразходвани (от предходна `session.proxy`, получила rate limit от ваша страна), и Auto ги пропуска навсякъде: повторно използване на warm sessions, търсене на exit точки и извикването към Proxy Finder. Така Auto няма да избере отново exit точката, която току-що сте указали да избягва.

`meta` също ви позволява да изградите собствени табла за управление: кои хостове са достигнали браузърното ниво днес, среден брой опити за доставка, съотношение на извличанията с решен challenge спрямо чистите заявки. Ако даден хост внезапно скочи от 2 кредита на 10, това е сигнал за decay на сесията, по който можете да вземете мерки, преди сметката ви да нарасне.

Пример, който комбинира и четирите:

```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 поддържа за всеки host, живеят вътре в услугата и няма какво да прегледате, когато дебъгвате неочакван разход от ваша страна. Изграждаме изглед на сесиите по хостове, за да виждате кешираните сесии, тяхната възраст, колко време ще останат активни и историята на стъпките (rung history) зад всяка от тях. Плюс бутон за ръчно премахване на сесия, когато целта ви се промени и знаете, че кешът е невалиден.

След това предстои по-строг контрол на разходите. Твърд лимит на кредитите за всяка заявка (никога не харчи повече от X за това извикване, върни коректна грешка, ако надхвърля) и режим "single-only" за екипи, чиито цели никога не изискват browser стъпка. И двете функционалности в момента са зад feature flags.

Смисълът на Auto е да не мислите кой продукт да извикате. Това не означава, че не можете да проверите какво се е случило. Всеки response връща използваната стъпка (rung) и изградената сесия. Прочетете тези две полета и ще знаете точно защо вашите извиквания струват толкова, колкото струват.