Device-Analyze API

Detectează browser, SO, dispozitiv și boți din orice User-Agent.

Ce puteți face?
Analiză în timp real

Descompune traficul pe dispozitiv și browser fără cookie-uri.

Direcționare A/B inteligentă

Servește layout-uri diferite utilizatorilor mobili vs. desktop.

Filtrare boți

Detectează crawlere malițioase care imită browsere legitime.

Încercați live
99.9 % Disponibilitate
93.5ms Răspuns
20 req/s
0.002 Credite / cerere

Inspect UA


POST https://api.yeb.to/v1/device-analyze
ParametruTipOblig.Descriere
api_key string da Your API key
ua string opțional User-Agent string (defaults to caller UA)

Exemplu

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

Exemplu de răspuns

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

Coduri de răspuns

CodDescriere
200 SuccessCerere procesată OK.
400 Bad RequestValidarea intrării a eșuat.
401 UnauthorizedCheie API lipsă sau incorectă.
403 ForbiddenCheie inactivă sau nepermisă.
429 Rate LimitPrea multe cereri.
500 Server ErrorEroare neașteptată.

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.

Întrebări frecvente

Se bazează pe baza de date open source WhichBrowser, actualizată săptămânal pentru dispozitive și motoare noi.

Nu – le hash-uim pentru metrici; valoarea brută este eliminată imediat după analiză.

Da. Fiecare cerere, chiar și cele care rezultă în erori, consumă credite. Creditele tale sunt legate de numărul de cereri, indiferent de succes sau eșec. Dacă eroarea este clar cauzată de o problemă a platformei din partea noastră, vom restaura creditele afectate (fără rambursări în numerar).

Contactați-ne la [email protected]. Luăm feedback-ul în serios—dacă raportul de bug sau cererea de funcționalitate este semnificativă, putem repara sau îmbunătăți API-ul rapid și vă acordăm 50 de credite gratuite ca mulțumire.

Depinde de API și uneori chiar de endpoint. Unele endpoint-uri folosesc date din surse externe, care pot avea limite mai stricte. De asemenea, aplicăm limite pentru a preveni abuzul și a menține platforma stabilă. Verificați documentația pentru limita specifică a fiecărui endpoint.

Funcționăm pe un sistem de credite. Creditele sunt unități preplătite, nerambursabile, pe care le cheltuiți pe apeluri API și instrumente. Creditele sunt consumate FIFO (cele mai vechi mai întâi) și sunt valabile 12 luni de la data achiziției. Panoul de control afișează fiecare dată de achiziție și expirarea sa.

Da. Toate creditele achiziționate (inclusiv soldurile fracționare) sunt valabile 12 luni de la achiziție. Creditele neutilizate expiră automat și sunt șterse permanent la sfârșitul perioadei de valabilitate. Creditele expirate nu pot fi restaurate sau convertite în numerar sau altă valoare. Regulă tranzitorie: creditele cumpărate înainte de 22 sept. 2025 sunt tratate ca achiziționate pe 22 sept. 2025 și expiră pe 22 sept. 2026 (cu excepția cazului în care a fost indicată o expirare anterioară la achiziție).

Da—în cadrul perioadei de valabilitate. Creditele neutilizate rămân disponibile și se transferă din lună în lună până expiră la 12 luni de la achiziție.

Creditele sunt nerambursabile. Cumpărați doar ce aveți nevoie—puteți oricând reîncărca mai târziu. Dacă o eroare a platformei cauzează o debitare eșuată, putem restaura creditele afectate după investigare. Fără rambursări în numerar.

Prețurile sunt stabilite în credite, nu în dolari. Fiecare endpoint are propriul cost—vedeți insigna „Credite / cerere" de mai sus. Veți ști întotdeauna exact cât cheltuiți.
← Înapoi la API-uri