Enhedsanalyse-API

Parse enhver User-Agent-streng til enhedstype, OS, browser og versionsdata.

Hvad kan du gøre?
Real-time analytics

Break down traffic by device & browser without cookies.

Smart A/B targeting

Serve different layouts to mobile vs. desktop users.

Bot filtering

Detect bad crawlers spoofing legit browsers.

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

Inspect UA


POST https://api.yeb.to/v1/device-analyze
ParameterTypePåkrævetBeskrivelse
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ørgsel behandlet OK.
400 Bad RequestInputvalidering mislykkedes.
401 UnauthorizedManglende / forkert API-nøgle.
403 ForbiddenNøgle inaktiv eller ikke tilladt.
429 Rate LimitFor mange forespørgsler.
500 Server ErrorUventet fejl.

Inspect

device-analyze 0.0020 credits

Parameters

API Key
query · string · required
User-Agent
query · string

Code Samples


                
                
                
            

Response

Status:
Headers

                
Body

                

Enhedsanalyse-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 stillede spørgsmål

Vi bruger en udvidet UA-parser med 50.000+ mønstre. Dækningen overstiger 99 % af virkelige browserstrenge.

Ja – almindelige crawlere, feedlæsere og overvågningsagenter identificeres og markeres.

Ja. Hver forespørgsel, selv dem der resulterer i fejl, forbruger kreditter. Dine kreditter er bundet til antallet af forespørgsler, uanset succes eller fejl. Hvis fejlen tydeligt skyldes et platformproblem på vores side, gendanner vi de berørte kreditter (ingen kontant refusion).

Kontakt os på [email protected]. Vi tager feedback alvorligt—hvis din fejlrapport eller funktionsanmodning er meningsfuld, kan vi rette eller forbedre API'et hurtigt og give dig 50 gratis kreditter som tak.

Det afhænger af API'et og nogle gange endda af endpointet. Nogle endpoints bruger data fra eksterne kilder, som kan have strengere grænser. Vi håndhæver også grænser for at forhindre misbrug og holde vores platform stabil. Se dokumentationen for den specifikke hastighedsgrænse for hvert endpoint.

Vi opererer med et kreditsystem. Kreditter er forudbetalte, ikke-refunderbare enheder, du bruger på API-kald og værktøjer. Kreditter forbruges FIFO (ældste først) og er gyldige i 12 måneder fra købsdatoen. Dashboardet viser hver købsdato og dens udløb.

Ja. Alle købte kreditter (inklusive brøkdele) er gyldige i 12 måneder fra købet. Ubrugte kreditter udløber automatisk og slettes permanent ved udgangen af gyldighedsperioden. Udløbne kreditter kan ikke gendannes eller konverteres til kontanter eller anden værdi. Overgangsregel: kreditter købt før 22. sep. 2025 behandles som købt den 22. sep. 2025 og udløber den 22. sep. 2026 (medmindre en tidligere udløbsdato var angivet ved købet).

Ja—inden for deres gyldighedsperiode. Ubrugte kreditter forbliver tilgængelige og overføres fra måned til måned, indtil de udløber 12 måneder efter købet.

Kreditter er ikke-refunderbare. Køb kun det, du har brug for—du kan altid fylde op senere. Hvis en platformfejl forårsager en mislykket opkrævning, kan vi gendanne de berørte kreditter efter undersøgelse. Ingen kontant refusion.

Priser er angivet i kreditter, ikke dollars. Hvert endpoint har sin egen pris—se mærket "Kreditter / forespørgsel" ovenfor. Du ved altid præcis, hvad du bruger.
← Tilbage til API'er