Device-Analyze API

Phát hiện trình duyệt, hệ điều hành, thiết bị và bot từ bất kỳ User-Agent nào.

Lấy API Key Mua tín dụng
Bạn có thể làm gì?
Phân tích thời gian thực

Phân tách lưu lượng theo thiết bị và trình duyệt mà không cần cookie.

Nhắm mục tiêu A/B thông minh

Phục vụ bố cục khác nhau cho người dùng di động và máy tính.

Lọc bot

Phát hiện trình thu thập độc hại giả mạo trình duyệt hợp lệ.

Dùng thử trực tiếp
99.9 % Thời gian hoạt động
93.4ms Phản hồi
20 req/s
0.002 Tín dụng / yêu cầu

Inspect UA


POST https://api.yeb.to/v1/device-analyze
Tham sốLoạiBắt buộcMô tả
api_key string Your API key
ua string tùy chọn User-Agent string (defaults to caller UA)

Ví dụ

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

Ví dụ phản hồi

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

Mã phản hồi

Mô tả
200 SuccessYêu cầu xử lý thành công.
400 Bad RequestXác thực đầu vào thất bại.
401 UnauthorizedAPI Key thiếu hoặc sai.
403 ForbiddenKey không hoạt động hoặc không được phép.
429 Rate LimitQuá nhiều yêu cầu.
500 Server ErrorLỗi không mong đợi.

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.

Câu hỏi thường gặp

Dựa trên cơ sở dữ liệu mã nguồn mở WhichBrowser, được cập nhật hàng tuần cho các thiết bị và engine mới.

Không – chúng tôi hash chúng cho số liệu; giá trị thô bị loại bỏ ngay sau khi phân tích.

Có. Mọi yêu cầu, kể cả những yêu cầu có lỗi, đều tiêu tốn tín dụng. Tín dụng của bạn được gắn với số lượng yêu cầu, bất kể thành công hay thất bại. Nếu lỗi rõ ràng do sự cố nền tảng từ phía chúng tôi, chúng tôi sẽ khôi phục tín dụng bị ảnh hưởng (không hoàn tiền mặt).

Liên hệ chúng tôi tại [email protected]. Chúng tôi coi trọng phản hồi—nếu báo cáo lỗi hoặc yêu cầu tính năng của bạn có ý nghĩa, chúng tôi có thể sửa hoặc cải thiện API nhanh chóng và tặng bạn 50 tín dụng miễn phí để cảm ơn.

Tùy thuộc vào API và đôi khi cả endpoint. Một số endpoint sử dụng dữ liệu từ nguồn bên ngoài, có thể có giới hạn nghiêm ngặt hơn. Chúng tôi cũng áp dụng giới hạn để ngăn chặn lạm dụng và duy trì sự ổn định của nền tảng. Kiểm tra tài liệu để biết giới hạn cụ thể cho mỗi endpoint.

Chúng tôi hoạt động theo hệ thống tín dụng. Tín dụng là các đơn vị trả trước, không hoàn lại mà bạn chi cho các cuộc gọi API và công cụ. Tín dụng được tiêu thụ theo FIFO (cũ nhất trước) và có hiệu lực 12 tháng kể từ ngày mua. Bảng điều khiển hiển thị ngày mua và ngày hết hạn của mỗi giao dịch.

Có. Tất cả tín dụng đã mua (bao gồm số dư lẻ) có hiệu lực 12 tháng kể từ ngày mua. Tín dụng chưa sử dụng tự động hết hạn và bị xóa vĩnh viễn khi kết thúc thời hạn hiệu lực. Tín dụng đã hết hạn không thể khôi phục hoặc chuyển đổi thành tiền mặt hay giá trị khác. Quy tắc chuyển tiếp: tín dụng mua trước ngày 22 tháng 9 năm 2025 được coi là mua vào ngày 22 tháng 9 năm 2025 và hết hạn vào ngày 22 tháng 9 năm 2026 (trừ khi ngày hết hạn sớm hơn được ghi khi mua).

Có—trong thời hạn hiệu lực. Tín dụng chưa sử dụng vẫn khả dụng và được chuyển từ tháng sang tháng cho đến khi hết hạn 12 tháng sau khi mua.

Tín dụng là không hoàn lại. Chỉ mua những gì bạn cần—bạn luôn có thể nạp thêm sau. Nếu lỗi nền tảng gây ra tính phí thất bại, chúng tôi có thể khôi phục tín dụng bị ảnh hưởng sau khi điều tra. Không hoàn tiền mặt.

Giá được tính bằng tín dụng, không phải đô la. Mỗi endpoint có chi phí riêng—xem huy hiệu "Tín dụng / yêu cầu" ở trên. Bạn luôn biết chính xác mình đang chi bao nhiêu.
← Quay lại API