Device-Analyze API

Böngésző, operációs rendszer, eszköz és botok felismerése bármilyen User-Agentből.

Mit tehetsz?
Valós idejű analitika

Bontsd le a forgalmat eszköz és böngésző szerint sütik nélkül.

Intelligens A/B célzás

Szolgálj ki különböző elrendezéseket mobil vs. asztali felhasználóknak.

Bot szűrés

Ismerd fel a rosszindulatú crawlereket, amelyek legitim böngészőket utánoznak.

Élő próba
99.9 % Üzemidő
93.4ms Válasz
20 req/s
0.002 Kreditek / kérés

Inspect UA


POST https://api.yeb.to/v1/device-analyze
ParaméterTípusKötelezőLeírás
api_key string igen Your API key
ua string opcionális User-Agent string (defaults to caller UA)

Példa

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)..."
}'

Válasz példa

{
  "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}

Válaszkódok

KódLeírás
200 SuccessKérés sikeresen feldolgozva.
400 Bad RequestBemeneti érvényesítés sikertelen.
401 UnauthorizedHiányzó / hibás API-kulcs.
403 ForbiddenKulcs inaktív vagy nem engedélyezett.
429 Rate LimitTúl sok kérés.
500 Server ErrorVáratlan hiba.

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 — 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.

Gyakran ismételt kérdések

A nyílt forráskódú WhichBrowser adatbázisra támaszkodik, amely hetente frissül új eszközökkel és motorokkal.

Nem – hash-eljük őket metrikákhoz; a nyers értéket azonnal eldobjuk az elemzés után.

Igen. Minden kérés, még a hibás is, krediteket fogyaszt. A kreditjei a kérések számához kötöttek, függetlenül a sikertől vagy kudartól. Ha a hiba egyértelműen a platform oldalán lévő probléma miatt van, visszaállítjuk az érintett krediteket (készpénz-visszatérítés nincs).

Lépjen kapcsolatba velünk a [email protected] címen. Komolyan vesszük a visszajelzéseket—ha a hibajelentése vagy funkciókérése értelmes, gyorsan javíthatjuk vagy fejleszthetjük az API-t, és 50 ingyenes kreditet adunk köszönetképpen.

Az API-tól és néha az endponttól is függ. Egyes endpointok külső forrásokból származó adatokat használnak, amelyeknek szigorúbb korlátai lehetnek. Korlátokat is érvényesítünk a visszaélés megelőzése és a platform stabilitásának fenntartása érdekében. Az egyes endpointok pontos korlátját a dokumentációban találja.

Kreditrendszerrel működünk. A kreditek előre fizetett, nem visszatéríthető egységek, amelyeket API-hívásokra és eszközökre költ. A kreditek FIFO-elv szerint (a legrégebbiek először) fogynak, és a vásárlás dátumától számított 12 hónapig érvényesek. Az irányítópult minden vásárlás dátumát és lejáratát mutatja.

Igen. Az összes megvásárolt kredit (beleértve a töredék egyenlegeket) 12 hónapig érvényes a vásárlástól. A fel nem használt kreditek automatikusan lejárnak és véglegesen törlődnek az érvényességi időszak végén. A lejárt kreditek nem állíthatók vissza, és nem válthatók készpénzre vagy más értékre. Átmeneti szabály: a 2025. szept. 22. előtt vásárolt kreditek úgy kezelendők, mintha 2025. szept. 22-én vásárolták volna, és 2026. szept. 22-én járnak le (hacsak a vásárláskor nem volt korábbi lejárat megadva).

Igen—az érvényességi időszakon belül. A fel nem használt kreditek elérhetők maradnak és hónapról hónapra átvihetők, amíg 12 hónappal a vásárlás után le nem járnak.

A kreditek nem visszatéríthetők. Csak annyit vegyen, amennyire szüksége van—bármikor feltölthet később. Ha platformhiba okoz sikertelen terhelést, az érintett krediteket vizsgálat után visszaállíthatjuk. Nincs készpénz-visszatérítés.

Az árak kreditekben vannak megadva, nem dollárban. Minden endpointnak saját ára van—lásd a „Kreditek / kérés" jelvényt fentebb. Mindig pontosan tudni fogja, mennyit költ.
← Vissza az API-khoz