Device-Analyze API

Rileva browser, SO, dispositivo e bot da qualsiasi User-Agent.

Cosa puoi fare?
Analisi in tempo reale

Suddividi il traffico per dispositivo e browser senza cookie.

Targeting A/B intelligente

Servi layout diversi agli utenti mobile vs. desktop.

Filtraggio bot

Rileva crawler malevoli che imitano browser legittimi.

Prova dal vivo
99.9 % Disponibilità
93.5ms Risposta
20 req/s
0.002 Crediti / richiesta

Inspect UA


POST https://api.yeb.to/v1/device-analyze
ParametroTipoRich.Descrizione
api_key string Your API key
ua string opz. User-Agent string (defaults to caller UA)

Esempio

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

Esempio di risposta

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

Codici di risposta

CodiceDescrizione
200 SuccessRichiesta elaborata OK.
400 Bad RequestValidazione input fallita.
401 UnauthorizedChiave API mancante o errata.
403 ForbiddenChiave inattiva o non consentita.
429 Rate LimitTroppe richieste.
500 Server ErrorErrore imprevisto.

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.

Domande frequenti

Si basa sul database open source WhichBrowser, aggiornato settimanalmente per nuovi dispositivi e motori.

No – le hashiamo per le metriche; il valore grezzo viene scartato immediatamente dopo l'analisi.

Sì. Ogni richiesta, anche quelle che generano errori, consuma crediti. I tuoi crediti sono legati al numero di richieste, indipendentemente dal successo o dal fallimento. Se l'errore è chiaramente dovuto a un problema della piattaforma da parte nostra, ripristineremo i crediti interessati (nessun rimborso in contanti).

Contattaci a [email protected]. Prendiamo i feedback seriamente—se la tua segnalazione di bug o richiesta di funzionalità è significativa, possiamo correggere o migliorare l'API rapidamente e concederti 50 crediti gratuiti come ringraziamento.

Dipende dall'API e a volte anche dall'endpoint. Alcuni endpoint utilizzano dati da fonti esterne, che possono avere limiti più rigorosi. Imponiamo anche limiti per prevenire abusi e mantenere la nostra piattaforma stabile. Consulta la documentazione per il limite specifico di ogni endpoint.

Operiamo con un sistema di crediti. I crediti sono unità prepagate e non rimborsabili che spendi per chiamate API e strumenti. I crediti vengono consumati in ordine FIFO (i più vecchi per primi) e sono validi per 12 mesi dalla data di acquisto. La dashboard mostra ogni data di acquisto e la sua scadenza.

Sì. Tutti i crediti acquistati (inclusi i saldi frazionari) sono validi per 12 mesi dall'acquisto. I crediti non utilizzati scadono automaticamente e vengono eliminati permanentemente alla fine del periodo di validità. I crediti scaduti non possono essere ripristinati o convertiti in contanti o altro valore. Regola transitoria: i crediti acquistati prima del 22 set. 2025 sono trattati come acquistati il 22 set. 2025 e scadono il 22 set. 2026 (salvo diversa scadenza indicata all'acquisto).

Sì—entro il periodo di validità. I crediti non utilizzati rimangono disponibili e vengono riportati di mese in mese fino alla scadenza 12 mesi dopo l'acquisto.

I crediti sono non rimborsabili. Acquista solo ciò di cui hai bisogno—puoi sempre ricaricare in seguito. Se un errore della piattaforma causa un addebito fallito, possiamo ripristinare i crediti interessati dopo indagine. Nessun rimborso in contanti.

I prezzi sono fissati in crediti, non in dollari. Ogni endpoint ha il proprio costo—vedi il badge "Crediti / richiesta" sopra. Saprai sempre esattamente quanto stai spendendo.
← Torna alle API