Device-Analyze API — Разпознаване на User-Agent | YEB

Разпознайте браузър, операционна система, тип устройство и ботове от всеки User-Agent низ. Аналитика в реално време, A/B таргетиране и филтриране на ботове без бисквитки.

Какво можете да правите?
Аналитика в реално време

Разбийте трафика по устройство и браузър без бисквитки.

Интелигентно A/B насочване

Показвайте различни оформления за мобилни и десктоп потребители.

Филтриране на ботове

Разпознавайте злонамерени краулъри, маскирани като легитимни браузъри.

Изпробвай на живо
99.9 % Време на работа
93.5ms Отговор
20 req/s
0.002 Кредити / заявка

Inspect UA


POST https://api.yeb.to/v1/device-analyze
ПараметърТипЗадл.Описание
api_key string да Your API key
ua string опц User-Agent string (defaults to caller UA)

Пример

curl -X POST https://api.yeb.to/v1/device-analyze \
  -H "Content-Type: application/json" \
  -d '{
  "api_key": "YOUR_KEY",
  "ua"     : "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)..."
}'

Пример за отговор

{
  "data": {
    "ua_string": "Mozilla/5.0 …",
    "browser": { "name": "Mobile Safari", "version": "17.0" },
    "engine":  { "name": "WebKit", "version": "617" },
    "os":      { "name": "iOS", "version": "17.0" },
    "device":  { "type": "mobile", "brand": "Apple", "model": "iPhone" },
    "is_mobile": true,
    "is_tablet": false,
    "is_bot": false,
    "is_desktop": false
  }
}
{"error":"Missing User-Agent string","code":422}

Кодове на отговор

КодОписание
200 SuccessЗаявката е обработена успешно.
400 Bad RequestНеуспешна валидация на входните данни.
401 UnauthorizedЛипсващ / грешен API ключ.
403 ForbiddenКлючът е неактивен или без достъп.
429 Rate LimitТвърде много заявки.
500 Server ErrorНеочаквана грешка.

Inspect

device-analyze 0.0020 credits

Parameters

API Key
query · string · required
User-Agent
query · string

Code Samples


                
                
                
            

Response

Status:
Headers

                
Body

                

Device-Analyze API — Разпознаване на User-Agent | YEB — Practical Guide

A hands-on guide to classifying browsers and devices from User-Agent strings. Learn when to send the UA, how to read the output, and what decisions to make in production (security, analytics, UX).

#What Device-Analyze solves

This endpoint parses a User-Agent (UA) string and returns browser, engine, OS, device and bot signals, plus convenient booleans (is_mobile, is_desktop, …). Use it to tailor UX (mobile vs desktop layouts), segment analytics, or flag suspicious UAs.

Works even if you don’t send ua: the API falls back to the current request’s User-Agent header.

#Endpoints & when to use them

# POST /v1/device-analyze

  • Best for: All UA parsing use-cases. Single, simple endpoint.
  • How it works: Provide a ua string (optional). If omitted, we read the request header.
  • Common uses: Feature flags (e.g., disable heavy effects on mobile), funnel analysis, anti-fraud heuristics.

#Quick start

curl -X POST "https://api.yeb.to/v1/device-analyze" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: <YOUR_API_KEY>" \
  -d '{
    "api_key": "<YOUR_API_KEY>",
    "ua": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
  }'
// JS Fetch example (Node/Browser)
await fetch("https://api.yeb.to/v1/device-analyze", {
  method: "POST",
  headers: {
    "Accept": "application/json",
    "Content-Type": "application/json",
    "X-API-Key": "<YOUR_API_KEY>"
  },
  body: JSON.stringify({
    api_key: "<YOUR_API_KEY>",
    ua: navigator.userAgent // or a server-provided UA
  })
}).then(r => r.json()).then(console.log);

#Parameters that actually matter

Param Required Practical guidance Why it matters
ua No Send the exact UA you want analyzed. If omitted, we’ll use the request header. Gives you control (e.g., batch-analyze stored logs) and avoids proxy/header quirks.
api_key or X-API-Key Yes Either include in JSON payload or in header (preferred: header). Authentication. Header keeps keys out of logs more safely.

#Reading & acting on responses

You typically read data.browser, data.os, data.device, and boolean flags like is_mobile.

{
  "data": {
    "ua_string": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ... Chrome/141.0.0.0 Safari/537.36",
    "browser": { "name": "Chrome", "version": "141.0.0.0", "vendor": null },
    "engine":  { "name": "Blink",  "version": null },
    "os":      { "name": "Windows","version": "10.0" },
    "device":  { "type": "desktop","brand": null,"model": null },
    "bot": null,
    "is_mobile": false,
    "is_tablet": false,
    "is_bot": false,
    "is_desktop": true
  },
  "response_code": 200,
  "response_time_ms": 118
}

#Key signals & decisions

  • is_mobile / is_tablet / is_desktop — pick layout, image sizes, feature flags.
  • bot object — treat as crawler: skip animations, block login, different rate limits.
  • browser.version — gate advanced features (e.g., WebGPU) behind minimum versions.
  • device.type — “mobile”, “tablet”, “desktop”, etc. for coarse segmentation.

#Errors you might see

HTTPWhenWhat to do
422 UA missing and no User-Agent header. Send ua explicitly or ensure your proxy forwards the header.
401/403 Invalid/missing API key. Place the key in X-API-Key header.

#Practical recipes

  • Mobile-first UI: if is_mobile → reduce bundle, enable compact nav, lazy-load heavy widgets.
  • Fraud hardening: if is_bot or UA looks impossible (e.g., iOS + Edge legacy) → challenge or block.
  • Analytics buckets: group by device.type and os.name for clean dashboards.

#Troubleshooting & field notes

  1. Empty vendor/version: some UA strings are intentionally reduced. Don’t fail hard; fall back to booleans.
  2. Proxy chains: ensure your edge forwards User-Agent unchanged if you rely on header fallback.
  3. Batch analysis: always pass ua explicitly to avoid environment/header differences.

#More response examples

Android Mobile (Chrome)
{
  "data": {
    "ua_string": "Mozilla/5.0 (Linux; Android 10; K) ... Chrome/138.0.0.0 Mobile Safari/537.36",
    "browser": { "name": "Chrome", "version": "138.0.0.0", "vendor": null },
    "engine":  { "name": "Blink", "version": null },
    "os":      { "name": "Android", "version": "10" },
    "device":  { "type": "mobile", "brand": null, "model": null },
    "bot": null,
    "is_mobile": true,
    "is_tablet": false,
    "is_bot": false,
    "is_desktop": false
  }
}

#API Changelog

2025-10-20
Normalized bot details (name, category, url) and hardened UA fallback to request header when no ua param is sent.
2025-10-15
Improved OS / device detection for Android 9–13 and desktop Linux distributions; added convenience booleans.
2025-10-05
Initial public release of Device-Analyze v1.

Често задавани въпроси

Базира се на базата данни с отворен код WhichBrowser, обновявана ежеседмично за нови устройства и двигатели.

Не -- хешираме ги за метрики; суровата стойност се изтрива веднага след парсване.

Да. Всяка заявка, дори тази с грешка, изразходва кредити. Това е така, защото кредитите ви са обвързани с броя заявки, независимо от успеха или неуспеха. Ако грешката е ясно по наша вина, ще възстановим засегнатите кредити (без парично възстановяване).

Свържете се с нас на [email protected]. Приемаме обратната връзка сериозно — ако докладът ви за бъг или заявката за функционалност е смислена, можем да поправим или подобрим API-то бързо и да ви предоставим 50 безплатни кредита като благодарност.

Зависи от API-то и понякога дори от конкретната крайна точка. Някои крайни точки използват данни от външни източници, които може да имат по-строги ограничения. Ние също налагаме лимити за предотвратяване на злоупотреби и поддържане стабилността на платформата. Проверете документацията за конкретния лимит на всяка крайна точка.

Работим на кредитна система. Кредитите са предплатени, невъзстановими единици, които изразходвате за API извиквания и инструменти. Кредитите се изразходват FIFO (първи закупен, първи използван) и са валидни 12 месеца от датата на покупка. Таблото показва датата на покупка и изтичането на всяка покупка.

Да. Всички закупени кредити (включително дробни баланси) са валидни 12 месеца от покупката. Неизползваните кредити автоматично изтичат и се изтриват окончателно в края на периода на валидност. Изтеклите кредити не могат да бъдат възстановени или конвертирани в пари или друга стойност. Преходно правило: кредити, закупени преди 22 септ. 2025 г., се третират като закупени на 22 септ. 2025 г. и изтичат на 22 септ. 2026 г. (освен ако не е посочено по-ранно изтичане при покупката).

Да — в рамките на периода им на валидност. Неизползваните кредити остават налични и се прехвърлят от месец на месец, докато не изтекат 12 месеца след покупката.

Кредитите са невъзстановими. Купувайте само каквото ви трябва — винаги можете да заредите по-късно. Ако грешка от наша страна причини неуспешно таксуване, може да възстановим засегнатите кредити след проверка. Без парично възстановяване.

Цените са определени в кредити, не в долари. Всяка крайна точка посочва собствената си цена — вижте бадж „Кредити / заявка" по-горе. Винаги ще знаете точно колко изразходвате.
← Обратно към API-тата