Device-Analyze API

Detete navegador, SO, dispositivo e bots de qualquer User-Agent.

O que pode fazer?
Análise em tempo real

Decomponha o tráfego por dispositivo e navegador sem cookies.

Segmentação A/B inteligente

Sirva layouts diferentes a utilizadores móveis vs. desktop.

Filtragem de bots

Detete crawlers maliciosos que imitam navegadores legítimos.

Experimentar ao vivo
99.9 % Disponibilidade
93.5ms Resposta
20 req/s
0.002 Créditos / requisição

Inspect UA


POST https://api.yeb.to/v1/device-analyze
ParâmetroTipoObrig.Descrição
api_key string sim Your API key
ua string opc. User-Agent string (defaults to caller UA)

Exemplo

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

Exemplo de resposta

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

Códigos de resposta

CódigoDescrição
200 SuccessRequisição processada OK.
400 Bad RequestValidação de entrada falhou.
401 UnauthorizedChave API em falta ou incorreta.
403 ForbiddenChave inativa ou não permitida.
429 Rate LimitDemasiadas requisições.
500 Server ErrorErro inesperado.

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.

Perguntas Frequentes

Baseia-se na base de dados open source WhichBrowser, atualizada semanalmente para novos dispositivos e motores.

Não – fazemos hash para métricas; o valor bruto é descartado imediatamente após a análise.

Sim. Cada requisição, mesmo as que resultam em erros, consome créditos. Seus créditos estão vinculados ao número de requisições, independentemente de sucesso ou falha. Se o erro for claramente devido a um problema da plataforma do nosso lado, restauraremos os créditos afetados (sem reembolsos em dinheiro).

Contacte-nos em [email protected]. Levamos o feedback a sério—se o seu relatório de bug ou pedido de funcionalidade for significativo, podemos corrigir ou melhorar a API rapidamente e conceder-lhe 50 créditos gratuitos como agradecimento.

Depende da API e às vezes até do endpoint. Alguns endpoints usam dados de fontes externas, que podem ter limites mais rigorosos. Também aplicamos limites para prevenir abusos e manter a nossa plataforma estável. Consulte a documentação para o limite específico de cada endpoint.

Operamos com um sistema de créditos. Créditos são unidades pré-pagas e não reembolsáveis que gasta em chamadas API e ferramentas. Os créditos são consumidos por FIFO (os mais antigos primeiro) e são válidos por 12 meses a partir da data de compra. O painel mostra cada data de compra e a sua expiração.

Sim. Todos os créditos comprados (incluindo saldos fracionários) são válidos por 12 meses a partir da compra. Créditos não utilizados expiram automaticamente e são permanentemente eliminados no final do período de validade. Créditos expirados não podem ser restaurados ou convertidos em dinheiro ou outro valor. Regra de transição: créditos comprados antes de 22 de set. de 2025 são tratados como comprados em 22 de set. de 2025 e expiram em 22 de set. de 2026 (salvo indicação de expiração anterior na compra).

Sim—dentro do período de validade. Os créditos não utilizados permanecem disponíveis e são transferidos de mês para mês até expirarem 12 meses após a compra.

Os créditos são não reembolsáveis. Compre apenas o que precisa—pode sempre recarregar depois. Se um erro da plataforma causar uma cobrança falhada, podemos restaurar os créditos afetados após investigação. Sem reembolsos em dinheiro.

Os preços são definidos em créditos, não em dólares. Cada endpoint tem o seu próprio custo—veja o selo "Créditos / requisição" acima. Saberá sempre exatamente quanto está a gastar.
← Voltar às APIs