Device-Analyze API — User-Agent-tunnistus | YEB

Tunnista selain, käyttöjärjestelmä, laitetyyppi ja botit mistä tahansa User-Agent-merkkijonosta. Tehosta reaaliaikaista analytiikkaa, A/B-kohdentamista ja bottisuodatusta ilman evästeitä.

Mitä voit tehdä?
Reaaliaikainen analytiikka

Erittele liikenne laitteen ja selaimen mukaan ilman evästeitä.

Älykäs A/B-kohdentaminen

Tarjoa eri asetteluja mobiili- vs. työpöytäkäyttäjille.

Bottien suodatus

Tunnista haitalliset crawlerit, jotka väärensivät laillisia selaimia.

Kokeile livenä
99.9 % Käytettävyys
93.5ms Vastaus
20 req/s
0.002 Krediitit / pyyntö

Inspect UA


POST https://api.yeb.to/v1/device-analyze
ParametriTyyppiVaadittuKuvaus
api_key string kyllä Your API key
ua string valinnainen User-Agent string (defaults to caller UA)

Esimerkki

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

Vastausesimerkki

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

Vastauskoodit

KoodiKuvaus
200 SuccessPyyntö käsitelty OK.
400 Bad RequestSyötteen validointi epäonnistui.
401 UnauthorizedAPI-avain puuttuu tai on väärä.
403 ForbiddenAvain ei-aktiivinen tai ei sallittu.
429 Rate LimitLiian monta pyyntöä.
500 Server ErrorOdottamaton virhe.

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

Usein kysytyt kysymykset

Se perustuu avoimen lähdekoodin WhichBrowser-tietokantaan, joka päivitetään viikoittain uusille laitteille ja moottoreille.

Ei – tiivistämme ne metriikalle; raaka-arvo hylätään välittömästi jäsennyksen jälkeen.

Kyllä. Jokainen pyyntö, myös virheelliset, kuluttaa krediittejä. Krediittisi on sidottu pyyntöjen määrään riippumatta onnistumisesta tai epäonnistumisesta. Jos virhe johtuu selvästi alustamme ongelmasta, palautamme vaikutetut krediitit (ei käteispalautuksia).

Ota meihin yhteyttä osoitteessa [email protected]. Otamme palautteen vakavasti—jos virheraporttisi tai ominaisuuspyyntösi on mielekäs, voimme korjata tai parantaa API:a nopeasti ja myöntää sinulle 50 ilmaista krediittiä kiitokseksi.

Se riippuu API:sta ja joskus jopa endpointista. Jotkut endpointit käyttävät ulkoisten lähteiden dataa, joilla voi olla tiukemmat rajat. Asetamme myös rajoja väärinkäytön estämiseksi ja alustamme vakauden ylläpitämiseksi. Tarkista dokumentaatiosta kunkin endpointin tarkka raja.

Toimimme krediittijärjestelmällä. Krediitit ovat ennakkoon maksettuja, ei-palautettavia yksiköitä, joita käytät API-kutsuihin ja työkaluihin. Krediitit kulutetaan FIFO-periaatteella (vanhimmat ensin) ja ne ovat voimassa 12 kuukautta ostopäivästä. Hallintapaneeli näyttää kunkin oston päivämäärän ja vanhenemisen.

Kyllä. Kaikki ostetut krediitit (mukaan lukien osittaiset saldot) ovat voimassa 12 kuukautta ostosta. Käyttämättömät krediitit vanhenevat automaattisesti ja poistetaan pysyvästi voimassaolokauden lopussa. Vanhentuneita krediittejä ei voi palauttaa tai muuntaa rahaksi tai muuksi arvoksi. Siirtymäsääntö: ennen 22.9.2025 ostetut krediitit käsitellään kuin ne olisi ostettu 22.9.2025, ja ne vanhenevat 22.9.2026 (ellei ostossa ilmoitettu aikaisempaa vanhenemista).

Kyllä—voimassaolokauden sisällä. Käyttämättömät krediitit pysyvät saatavilla ja siirtyvät kuukaudesta toiseen, kunnes ne vanhenevat 12 kuukautta oston jälkeen.

Krediitit ovat ei-palautettavia. Osta vain tarvitsemasi—voit aina ladata lisää myöhemmin. Jos alustavirhe aiheuttaa epäonnistuneen veloituksen, voimme palauttaa vaikutetut krediitit tutkimuksen jälkeen. Ei käteispalautuksia.

Hinnat on asetettu krediiteissä, ei dollareissa. Jokaisella endpointilla on oma hintansa—katso "Krediitit / pyyntö" -merkki yllä. Tiedät aina tarkalleen, mitä käytät.
← Takaisin API:hin