Geräteanalyse-API

Parsen Sie jeden User-Agent-String in Gerätetyp, OS, Browser und Versionsdaten.

Was können Sie tun?
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.

Live testen
99.9 % Verfügbarkeit
93.5ms Antwort
20 req/s
0.002 Credits / Anfrage

Inspect UA


POST https://api.yeb.to/v1/device-analyze
ParameterTypErf.Beschreibung
api_key string ja Your API key
ua string opt. User-Agent string (defaults to caller UA)

Beispiel

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

Antwortbeispiel

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

Antwortcodes

CodeBeschreibung
200 SuccessAnfrage erfolgreich verarbeitet.
400 Bad RequestEingabevalidierung fehlgeschlagen.
401 UnauthorizedFehlender / falscher API-Schlüssel.
403 ForbiddenSchlüssel inaktiv oder nicht erlaubt.
429 Rate LimitZu viele Anfragen.
500 Server ErrorUnerwarteter Fehler.

Inspect

device-analyze 0.0020 credits

Parameters

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

Code Samples


                
                
                
            

Response

Status:
Headers

                
Body

                

Geräteanalyse-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.

Häufig gestellte Fragen

Wir verwenden einen erweiterten UA-Parser mit über 50.000 Mustern. Die Abdeckung übersteigt 99 % der realen Browser-Strings.

Ja – gängige Crawler, Feed-Reader und Monitoring-Agenten werden identifiziert und markiert.

Ja. Jede Anfrage, auch solche mit Fehlern, verbraucht Credits. Ihre Credits sind an die Anzahl der Anfragen gebunden, unabhängig von Erfolg oder Misserfolg. Wenn der Fehler eindeutig auf ein Plattformproblem unsererseits zurückzuführen ist, stellen wir die betroffenen Credits wieder her (keine Barerstattung).

Kontaktieren Sie uns unter [email protected]. Wir nehmen Feedback ernst—wenn Ihr Fehlerbericht oder Ihre Funktionsanfrage sinnvoll ist, können wir die API schnell korrigieren oder verbessern und Ihnen 50 kostenlose Credits als Dankeschön gewähren.

Es hängt von der API und manchmal sogar vom Endpoint ab. Einige Endpoints nutzen Daten aus externen Quellen, die strengere Limits haben können. Wir setzen auch Limits durch, um Missbrauch zu verhindern und unsere Plattform stabil zu halten. Prüfen Sie die Dokumentation für das spezifische Limit jedes Endpoints.

Wir arbeiten mit einem Creditsystem. Credits sind vorausbezahlte, nicht erstattungsfähige Einheiten, die Sie für API-Aufrufe und Tools ausgeben. Credits werden nach dem FIFO-Prinzip (älteste zuerst) verbraucht und sind 12 Monate ab Kaufdatum gültig. Das Dashboard zeigt jedes Kaufdatum und dessen Ablauf an.

Ja. Alle gekauften Credits (einschließlich Teilguthaben) sind 12 Monate ab Kauf gültig. Ungenutzte Credits verfallen automatisch und werden am Ende der Gültigkeitsdauer dauerhaft gelöscht. Verfallene Credits können nicht wiederhergestellt oder in Bargeld oder anderen Wert umgewandelt werden. Übergangsregel: Vor dem 22. Sep. 2025 gekaufte Credits gelten als am 22. Sep. 2025 gekauft und verfallen am 22. Sep. 2026 (sofern beim Kauf kein früherer Ablauf angegeben wurde).

Ja—innerhalb ihrer Gültigkeitsdauer. Ungenutzte Credits bleiben verfügbar und werden von Monat zu Monat übertragen, bis sie 12 Monate nach dem Kauf verfallen.

Credits sind nicht erstattungsfähig. Kaufen Sie nur, was Sie brauchen—Sie können jederzeit nachladen. Wenn ein plattformseitiger Fehler eine fehlgeschlagene Abbuchung verursacht, können wir die betroffenen Credits nach Prüfung wiederherstellen. Keine Barerstattung.

Preise werden in Credits angegeben, nicht in Dollar. Jeder Endpoint hat seine eigenen Kosten—siehe das Abzeichen „Credits / Anfrage" oben. Sie wissen immer genau, was Sie ausgeben.
← Zurück zu den APIs