Device-Analyze API

Oppdag nettleser, OS, enhet og roboter fra enhver User-Agent.

Hva kan du gjøre?
Sanntidsanalyse

Bryt ned trafikk etter enhet og nettleser uten informasjonskapsler.

Smart A/B-målretting

Lever ulike oppsett til mobil- vs. skrivebordsbrukere.

Bot-filtrering

Oppdag ondsinnede crawlere som utgir seg for legitime nettlesere.

Prøv live
99.9 % Oppetid
93.5ms Svar
20 req/s
0.002 Kreditter / forespørsel

Inspect UA


POST https://api.yeb.to/v1/device-analyze
ParameterTypePåkrevdBeskrivelse
api_key string ja Your API key
ua string valgfri User-Agent string (defaults to caller UA)

Eksempel

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

Svareksempel

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

Svarkoder

KodeBeskrivelse
200 SuccessForespørsel behandlet OK.
400 Bad RequestInngangsvalidering mislyktes.
401 UnauthorizedManglende / feil API-nøkkel.
403 ForbiddenNøkkel inaktiv eller ikke tillatt.
429 Rate LimitFor mange forespørsler.
500 Server ErrorUventet feil.

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.

Ofte stilte spørsmål

Den bygger på åpen kildekode WhichBrowser-databasen, oppdatert ukentlig for nye enheter og motorer.

Nei – vi hasher dem for metrikk; råverdien forkastes umiddelbart etter parsing.

Ja. Hver forespørsel, selv de som resulterer i feil, forbruker kreditter. Kredittene dine er knyttet til antall forespørsler, uavhengig av suksess eller feil. Hvis feilen tydelig skyldes et plattformproblem på vår side, gjenoppretter vi de berørte kredittene (ingen kontantrefusjon).

Kontakt oss på [email protected]. Vi tar tilbakemeldinger på alvor—hvis feilrapporten eller funksjonsforespørselen din er meningsfull, kan vi fikse eller forbedre API-et raskt og gi deg 50 gratis kreditter som takk.

Det avhenger av API-et og noen ganger til og med av endepunktet. Noen endepunkter bruker data fra eksterne kilder, som kan ha strengere grenser. Vi håndhever også grenser for å forhindre misbruk og holde plattformen stabil. Sjekk dokumentasjonen for den spesifikke grensen for hvert endepunkt.

Vi opererer med et kredittsystem. Kreditter er forhåndsbetalte, ikke-refunderbare enheter du bruker på API-kall og verktøy. Kreditter forbrukes etter FIFO-prinsippet (eldste først) og er gyldige i 12 måneder fra kjøpsdatoen. Dashbordet viser hver kjøpsdato og dens utløp.

Ja. Alle kjøpte kreditter (inkludert brøkdeler) er gyldige i 12 måneder fra kjøpet. Ubrukte kreditter utløper automatisk og slettes permanent ved slutten av gyldighetsperioden. Utløpte kreditter kan ikke gjenopprettes eller konverteres til kontanter eller annen verdi. Overgangsregel: kreditter kjøpt før 22. sep. 2025 behandles som kjøpt 22. sep. 2025 og utløper 22. sep. 2026 (med mindre en tidligere utløpsdato ble oppgitt ved kjøpet).

Ja—innenfor gyldighetsperioden. Ubrukte kreditter forblir tilgjengelige og overføres fra måned til måned til de utløper 12 måneder etter kjøpet.

Kreditter er ikke-refunderbare. Kjøp bare det du trenger—du kan alltid fylle på senere. Hvis en plattformfeil forårsaker en mislykket belastning, kan vi gjenopprette de berørte kredittene etter undersøkelse. Ingen kontantrefusjon.

Prisene er satt i kreditter, ikke dollar. Hvert endepunkt har sin egen pris—se merket «Kreditter / forespørsel» ovenfor. Du vet alltid nøyaktig hva du bruker.
← Tilbake til API-er