Device-Analyze API

Detecteer browser, OS, apparaat en bots vanuit elke User-Agent.

Wat kunt u doen?
Realtime analytics

Splits verkeer op per apparaat & browser zonder cookies.

Slimme A/B-targeting

Serveer verschillende lay-outs aan mobiele vs. desktopgebruikers.

Botfiltering

Detecteer kwaadaardige crawlers die legitieme browsers nabootsen.

Live proberen
99.9 % Beschikbaarheid
93.5ms Antwoord
20 req/s
0.002 Credits / verzoek

Inspect UA


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

Voorbeeld

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

Antwoordvoorbeeld

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

Antwoordcodes

CodeBeschrijving
200 SuccessVerzoek succesvol verwerkt.
400 Bad RequestInvoervalidatie mislukt.
401 UnauthorizedOntbrekende / onjuiste API-sleutel.
403 ForbiddenSleutel inactief of niet toegestaan.
429 Rate LimitTe veel verzoeken.
500 Server ErrorOnverwachte fout.

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.

Veelgestelde vragen

Gebaseerd op de open-source WhichBrowser-database, wekelijks bijgewerkt voor nieuwe apparaten en engines.

Nee – we hashen ze voor metrieken; de ruwe waarde wordt direct na parsing verwijderd.

Ja. Elk verzoek, zelfs die met fouten, verbruikt credits. Uw credits zijn gekoppeld aan het aantal verzoeken, ongeacht succes of falen. Als de fout duidelijk te wijten is aan een platformprobleem aan onze kant, herstellen we de getroffen credits (geen geldteruggave).

Neem contact met ons op via [email protected]. We nemen feedback serieus—als uw bugrapport of functieverzoek zinvol is, kunnen we de API snel repareren of verbeteren en u 50 gratis credits geven als dank.

Het hangt af van de API en soms zelfs van het endpoint. Sommige endpoints gebruiken gegevens van externe bronnen, die strengere limieten kunnen hebben. We handhaven ook limieten om misbruik te voorkomen en ons platform stabiel te houden. Raadpleeg de documentatie voor de specifieke limiet van elk endpoint.

We werken met een creditsysteem. Credits zijn vooruitbetaalde, niet-restitueerbare eenheden die u besteedt aan API-aanroepen en tools. Credits worden verbruikt volgens FIFO (oudste eerst) en zijn geldig voor 12 maanden vanaf de aankoopdatum. Het dashboard toont elke aankoopdatum en de vervaldatum.

Ja. Alle gekochte credits (inclusief fractionele saldi) zijn geldig voor 12 maanden na aankoop. Ongebruikte credits verlopen automatisch en worden permanent verwijderd aan het einde van de geldigheidsperiode. Verlopen credits kunnen niet worden hersteld of omgezet in contant geld of andere waarde. Overgangsregel: credits gekocht vóór 22 sep. 2025 worden behandeld als gekocht op 22 sep. 2025 en verlopen op 22 sep. 2026 (tenzij een eerdere vervaldatum werd vermeld bij aankoop).

Ja—binnen hun geldigheidsperiode. Ongebruikte credits blijven beschikbaar en worden van maand tot maand overgedragen totdat ze 12 maanden na aankoop verlopen.

Credits zijn niet-restitueerbaar. Koop alleen wat u nodig heeft—u kunt altijd later bijvullen. Als een platformfout een mislukte afschrijving veroorzaakt, kunnen we de getroffen credits herstellen na onderzoek. Geen geldteruggave.

Prijzen worden vastgesteld in credits, niet in dollars. Elk endpoint heeft zijn eigen kosten—zie de badge "Credits / verzoek" hierboven. U weet altijd precies wat u uitgeeft.
← Terug naar API's