Device-Analyze API

Détectez le navigateur, l'OS, l'appareil et les bots à partir de n'importe quel User-Agent.

Que pouvez-vous faire ?
Analytique en temps réel

Décomposez le trafic par appareil et navigateur sans cookies.

Ciblage A/B intelligent

Servez des mises en page différentes aux utilisateurs mobiles vs. bureau.

Filtrage de bots

Détectez les crawlers malveillants usurpant des navigateurs légitimes.

Essayer en direct
99.9 % Disponibilité
93.5ms Réponse
20 req/s
0.002 Crédits / requête

Inspect UA


POST https://api.yeb.to/v1/device-analyze
ParamètreTypeReq.Description
api_key string oui Your API key
ua string opt. User-Agent string (defaults to caller UA)

Exemple

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

Exemple de réponse

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

Codes de réponse

CodeDescription
200 SuccessRequête traitée avec succès.
400 Bad RequestValidation d'entrée échouée.
401 UnauthorizedClé API manquante ou incorrecte.
403 ForbiddenClé inactive ou non autorisée.
429 Rate LimitTrop de requêtes.
500 Server ErrorErreur inattendue.

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.

Questions fréquemment posées

Il s'appuie sur la base de données open source WhichBrowser, mise à jour chaque semaine pour les nouveaux appareils et moteurs.

Non – nous les hachons pour les métriques ; la valeur brute est supprimée immédiatement après l'analyse.

Oui. Chaque requête, même celles qui entraînent des erreurs, consomme des crédits. Vos crédits sont liés au nombre de requêtes, indépendamment du succès ou de l'échec. Si l'erreur est clairement due à un problème de plateforme de notre côté, nous restaurerons les crédits affectés (pas de remboursement en espèces).

Contactez-nous à [email protected]. Nous prenons les retours au sérieux—si votre rapport de bug ou demande de fonctionnalité est pertinent, nous pouvons corriger ou améliorer l'API rapidement et vous accorder 50 crédits gratuits en guise de remerciement.

Cela dépend de l'API et parfois même du endpoint. Certains endpoints utilisent des données de sources externes, qui peuvent avoir des limites plus strictes. Nous imposons également des limites pour prévenir les abus et maintenir la stabilité de notre plateforme. Consultez la documentation pour la limite spécifique de chaque endpoint.

Nous fonctionnons avec un système de crédits. Les crédits sont des unités prépayées et non remboursables que vous dépensez pour les appels API et les outils. Les crédits sont consommés en FIFO (les plus anciens en premier) et sont valables 12 mois à compter de la date d'achat. Le tableau de bord affiche chaque date d'achat et son expiration.

Oui. Tous les crédits achetés (y compris les soldes fractionnaires) sont valables 12 mois à compter de l'achat. Les crédits inutilisés expirent automatiquement et sont définitivement supprimés à la fin de la période de validité. Les crédits expirés ne peuvent être restaurés ni convertis en espèces ou autre valeur. Règle transitoire : les crédits achetés avant le 22 sept. 2025 sont traités comme achetés le 22 sept. 2025 et expirent le 22 sept. 2026 (sauf si une expiration antérieure a été indiquée lors de l'achat).

Oui—dans leur période de validité. Les crédits inutilisés restent disponibles et sont reportés de mois en mois jusqu'à leur expiration 12 mois après l'achat.

Les crédits sont non remboursables. N'achetez que ce dont vous avez besoin—vous pouvez toujours recharger plus tard. Si une erreur de plateforme cause un échec de facturation, nous pouvons restaurer les crédits affectés après enquête. Pas de remboursement en espèces.

Les prix sont fixés en crédits, pas en dollars. Chaque endpoint a son propre coût—voir le badge « Crédits / requête » ci-dessus. Vous saurez toujours exactement ce que vous dépensez.
← Retour aux APIs