Device-Analyze API

任意のUser-Agentからブラウザ、OS、デバイス、ボットを検出します。

何ができますか?
リアルタイム分析

Cookieなしでデバイスとブラウザごとにトラフィックを分析します。

スマートA/Bターゲティング

モバイルとデスクトップユーザーに異なるレイアウトを提供します。

ボットフィルタリング

正規のブラウザを偽装する悪意のあるクローラーを検出します。

ライブで試す
99.9 % 稼働時間
93.4ms レスポンス
20 req/s
0.002 クレジット / リクエスト

Inspect UA


POST https://api.yeb.to/v1/device-analyze
パラメータ必須説明
api_key string はい Your API key
ua string 任意 User-Agent string (defaults to caller UA)

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

レスポンス例

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

レスポンスコード

コード説明
200 Successリクエスト処理成功。
400 Bad Request入力バリデーション失敗。
401 UnauthorizedAPIキーが不足または不正。
403 Forbiddenキーが無効または許可されていません。
429 Rate Limitリクエストが多すぎます。
500 Server Error予期しないエラー。

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.

よくある質問

オープンソースのWhichBrowserデータベースに基づいており、新しいデバイスとエンジンに対して毎週更新されます。

いいえ – メトリクス用にハッシュ化します。生の値は解析後すぐに破棄されます。

はい。エラーが発生したリクエストを含め、すべてのリクエストがクレジットを消費します。クレジットは成功・失敗に関係なくリクエスト数に紐づいています。エラーが明らかに当社のプラットフォーム側の問題による場合は、影響を受けたクレジットを復元します(現金での返金はありません)。

[email protected]までご連絡ください。フィードバックを真摯に受け止めています。バグレポートや機能リクエストが意味のあるものであれば、APIを迅速に修正・改善し、お礼として50の無料クレジットを付与します。

APIやエンドポイントによって異なります。一部のエンドポイントは外部ソースのデータを使用しており、より厳しい制限がある場合があります。また、不正利用の防止とプラットフォームの安定性維持のために制限を設けています。各エンドポイントの具体的な制限についてはドキュメントをご確認ください。

クレジットシステムで運営しています。クレジットは前払いの返金不可の単位で、API呼び出しやツールに使用します。クレジットはFIFO(古いものから順に)消費され、購入日から12か月間有効です。ダッシュボードに各購入日とその有効期限が表示されます。

はい。購入したすべてのクレジット(端数残高を含む)は購入から12か月間有効です。未使用のクレジットは有効期間終了時に自動的に期限切れとなり、永久に削除されます。期限切れのクレジットは復元や現金その他の価値への変換はできません。経過措置:2025年9月22日以前に購入したクレジットは2025年9月22日購入として扱われ、2026年9月22日に期限切れとなります(購入時により早い期限が記載されていない限り)。

はい—有効期間内で繰り越されます。未使用のクレジットは利用可能な状態のまま月ごとに繰り越され、購入後12か月で期限切れになります。

クレジットは返金不可です。必要な分だけ購入してください—後からいつでもチャージできます。プラットフォーム側のエラーで課金に失敗した場合、調査後に影響を受けたクレジットを復元する場合があります。現金での返金はありません。

料金はドルではなくクレジットで設定されています。各エンドポイントには独自のコストがあります—上記の「クレジット / リクエスト」バッジをご覧ください。常に正確な支出額がわかります。
← APIに戻る