Device-Analyze API

Deteksi browser, OS, perangkat, dan bot dari User-Agent apa pun.

Apa yang bisa Anda lakukan?
Analitik real-time

Uraikan lalu lintas berdasarkan perangkat & browser tanpa cookies.

Penargetan A/B pintar

Sajikan tata letak berbeda untuk pengguna mobile vs. desktop.

Penyaringan bot

Deteksi crawler jahat yang menyamar sebagai browser sah.

Coba Langsung
99.9 % Waktu Aktif
93.5ms Respons
20 req/s
0.002 Kredit / permintaan

Inspect UA


POST https://api.yeb.to/v1/device-analyze
ParameterTipeWajibDeskripsi
api_key string ya Your API key
ua string opsional User-Agent string (defaults to caller UA)

Contoh

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

Contoh Respons

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

Kode Respons

KodeDeskripsi
200 SuccessPermintaan diproses OK.
400 Bad RequestValidasi input gagal.
401 UnauthorizedKunci API hilang / salah.
403 ForbiddenKunci tidak aktif atau tidak diizinkan.
429 Rate LimitTerlalu banyak permintaan.
500 Server ErrorKegagalan tak terduga.

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.

Pertanyaan yang Sering Diajukan

Bergantung pada database open source WhichBrowser, diperbarui setiap minggu untuk perangkat dan engine baru.

Tidak – kami hash untuk metrik; nilai mentah dibuang segera setelah parsing.

Ya. Setiap permintaan, bahkan yang menghasilkan error, mengonsumsi kredit. Kredit Anda terkait dengan jumlah permintaan, terlepas dari keberhasilan atau kegagalan. Jika error jelas disebabkan oleh masalah platform di pihak kami, kami akan memulihkan kredit yang terpengaruh (tanpa pengembalian uang tunai).

Hubungi kami di [email protected]. Kami menganggap umpan balik serius—jika laporan bug atau permintaan fitur Anda bermakna, kami dapat memperbaiki atau meningkatkan API dengan cepat dan memberikan Anda 50 kredit gratis sebagai terima kasih.

Tergantung pada API dan terkadang bahkan pada endpoint. Beberapa endpoint menggunakan data dari sumber eksternal, yang mungkin memiliki batas lebih ketat. Kami juga menerapkan batas untuk mencegah penyalahgunaan dan menjaga stabilitas platform kami. Periksa dokumentasi untuk batas spesifik setiap endpoint.

Kami beroperasi dengan sistem kredit. Kredit adalah unit prabayar yang tidak dapat dikembalikan yang Anda gunakan untuk panggilan API dan alat. Kredit dikonsumsi secara FIFO (yang terlama lebih dulu) dan berlaku selama 12 bulan sejak tanggal pembelian. Dashboard menampilkan setiap tanggal pembelian dan masa berlakunya.

Ya. Semua kredit yang dibeli (termasuk saldo pecahan) berlaku selama 12 bulan sejak pembelian. Kredit yang tidak digunakan kedaluwarsa secara otomatis dan dihapus secara permanen di akhir masa berlaku. Kredit yang kedaluwarsa tidak dapat dipulihkan atau dikonversi menjadi uang tunai atau nilai lainnya. Aturan transisi: kredit yang dibeli sebelum 22 Sep 2025 diperlakukan sebagai dibeli pada 22 Sep 2025 dan kedaluwarsa pada 22 Sep 2026 (kecuali kedaluwarsa lebih awal dinyatakan saat pembelian).

Ya—dalam masa berlakunya. Kredit yang tidak digunakan tetap tersedia dan dialihkan dari bulan ke bulan hingga kedaluwarsa 12 bulan setelah pembelian.

Kredit tidak dapat dikembalikan. Beli hanya yang Anda butuhkan—Anda selalu bisa mengisi ulang nanti. Jika error platform menyebabkan tagihan gagal, kami dapat memulihkan kredit yang terpengaruh setelah penyelidikan. Tidak ada pengembalian uang tunai.

Harga ditetapkan dalam kredit, bukan dolar. Setiap endpoint memiliki biayanya sendiri—lihat lencana "Kredit / permintaan" di atas. Anda akan selalu tahu persis berapa yang Anda keluarkan.
← Kembali ke API