Device-Analyze API

Wykryj przeglądarkę, system operacyjny, urządzenie i boty z dowolnego User-Agent.

Co możesz zrobić?
Analityka w czasie rzeczywistym

Podziel ruch według urządzenia i przeglądarki bez plików cookie.

Inteligentne targetowanie A/B

Serwuj różne układy użytkownikom mobilnym vs. desktopowym.

Filtrowanie botów

Wykrywaj złośliwe crawlery podszywające się pod legalne przeglądarki.

Wypróbuj na żywo
99.9 % Dostępność
93.4ms Odpowiedź
20 req/s
0.002 Kredyty / żądanie

Inspect UA


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

Przykład

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

Przykład odpowiedzi

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

Kody odpowiedzi

KodOpis
200 SuccessŻądanie przetworzone OK.
400 Bad RequestWalidacja danych wejściowych nie powiodła się.
401 UnauthorizedBrakujący / nieprawidłowy klucz API.
403 ForbiddenKlucz nieaktywny lub niedozwolony.
429 Rate LimitZbyt wiele żądań.
500 Server ErrorNieoczekiwany błąd.

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.

Często zadawane pytania

Opiera się na bazie danych open source WhichBrowser, aktualizowanej co tydzień dla nowych urządzeń i silników.

Nie – hashujemy je dla metryk; surowa wartość jest odrzucana natychmiast po parsowaniu.

Tak. Każde żądanie, nawet te zakończone błędem, zużywa kredyty. Twoje kredyty są powiązane z liczbą żądań, niezależnie od sukcesu lub niepowodzenia. Jeśli błąd jest wyraźnie spowodowany problemem platformy po naszej stronie, przywrócimy dotknięte kredyty (bez zwrotów gotówkowych).

Skontaktuj się z nami pod adresem [email protected]. Traktujemy opinie poważnie—jeśli Twój raport o błędzie lub prośba o funkcję jest sensowna, możemy szybko naprawić lub ulepszyć API i przyznać Ci 50 darmowych kredytów w podziękowaniu.

Zależy od API, a czasem nawet od endpointu. Niektóre endpointy korzystają z danych ze źródeł zewnętrznych, które mogą mieć surowsze limity. Wprowadzamy też limity, aby zapobiec nadużyciom i utrzymać stabilność platformy. Sprawdź dokumentację, aby poznać konkretny limit dla każdego endpointu.

Działamy w systemie kredytowym. Kredyty to przedpłacone, bezzwrotne jednostki, które wydajesz na wywołania API i narzędzia. Kredyty są zużywane metodą FIFO (najstarsze najpierw) i są ważne przez 12 miesięcy od daty zakupu. Panel wyświetla datę każdego zakupu i jego wygaśnięcia.

Tak. Wszystkie zakupione kredyty (w tym ułamkowe salda) są ważne przez 12 miesięcy od zakupu. Niewykorzystane kredyty automatycznie wygasają i są trwale usuwane na koniec okresu ważności. Wygasłych kredytów nie można przywrócić ani zamienić na gotówkę lub inną wartość. Reguła przejściowa: kredyty zakupione przed 22 wrz. 2025 traktowane są jako zakupione 22 wrz. 2025 i wygasają 22 wrz. 2026 (chyba że przy zakupie podano wcześniejszą datę wygaśnięcia).

Tak—w ramach okresu ważności. Niewykorzystane kredyty pozostają dostępne i są przenoszone z miesiąca na miesiąc, aż wygasną 12 miesięcy po zakupie.

Kredyty są bezzwrotne. Kupuj tylko to, czego potrzebujesz—zawsze możesz doładować później. Jeśli błąd platformy spowoduje nieudane obciążenie, możemy przywrócić dotknięte kredyty po zbadaniu sprawy. Bez zwrotów gotówkowych.

Ceny są ustalane w kredytach, nie w dolarach. Każdy endpoint ma własną cenę—zobacz odznakę „Kredyty / żądanie" powyżej. Zawsze będziesz dokładnie wiedzieć, ile wydajesz.
← Powrót do API