WURFL

FREEMIUM
Verified
Door ScientiaMobile | Bijgewerkt il y a 4 jours | Data
Health Check

N/A

README

WURFL API

WURFL is a set of API for Device Detection. With WURFL, you can map HTTP request headers (notably the user-agent string) to properties (capabilities) of the client (AKA the User Agent) such as: the make and model of the device (for ex: OnePlus 7 Pro), the browser and its version (for ex, Chrome 89.0.4389.105), the OS and version, display size, form factor, and many other features that are not easily obtainable otherwise. WURFL does this by accessing a proprietary repository of device information containing the profiles of tens of thousands devices and browsers available around the world.

WURFL on RapidAPI is available through three different endpoints (lookuprequest,lookupuseragent and lookupdeviceid) that can be accessed to get device information. The endpoints will offer access to different sets of WURFL capabilities, with more expensive plans (four plans: BASIC, PRO, ULTRA and MEGA) offering additional properties (see below). Endpoints return the same response type. All enpoints must be called using the POST HTTP method.

Endpoint lookuprequest: Lookup a device by its HTTP request headers

Device detection can be performed through lookuprequest.

Here’s an input payload example:

{
    "lookup_headers": {
        "User-Agent": "Mozilla/5.0 (Linux; Android 6.0; ASUS_Z017D Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.98 Mobile Safari/537.36",
        "content-Type": "application/json",
        "x-requested-with":"XMLHttpRequest"
    },
}

The lookup_headers is made of all the headers found into an HTTP request.

Sending this payload using one of the RapidAPI code snippets returns this response (BASIC plan. More capabilities are available though the PRO, ULTRA and MEGA plans):

{ capabilities:
   { is_smarttv: 'false',
     is_smartphone: 'true',
     is_phone: 'true',
     brand_name: 'Asus',
     wurfl_id: 'asus_z017d_ver1',
     model_name: 'Z017D',
     is_mobile: 'true',
     marketing_name: 'Zenfone 3 ZE520KL',
     is_tablet: 'false',
     is_touchscreen: 'true',
     complete_device_name: 'Asus Z017D (Zenfone 3 ZE520KL)',
     is_full_desktop: 'false',
     form_factor: 'Smartphone',
     is_robot: 'false' },
  error: '' }

If an error occurs, the error field will report the error message.
By default, the API will return all the capabilities supported by the endpoint. If you don’t need all the capabilities, you can set the list of the desired capabilities in the input payload:

{
    "lookup_headers": {
        "User-Agent": "Mozilla/5.0 (Linux; Android 6.0; ASUS_Z017D Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.98 Mobile Safari/537.36"
        "content-Type": "application/json",
        "x-requested-with":"XMLHttpRequest"
    },
    "requested_caps":["brand_name"],
    "requested_vcaps":["form_factor"]
}

In this case, the response will be:

{ 
    capabilities:
   { 
         form_factor: 'Smartphone',
         wurfl_id: 'asus_z017d_ver1',
         brand_name: 'Asus' 
  },
    error: '' 
}

Static Capabilities vs. Virtual Capabilities

From a usage perspective, there is no practical difference between a static and a virtual capability. Under the hood, though, virtual capabilities have an algorithmical component that may be CPU intensive. For this reason they are calculated on request. API users need to be aware of this difference and request virtual and static capabilities separately.

For more information about the difference between static caps (capabilities)and vcaps (“virtual capabilities”), see: WURFL capabilities docs

Endpoint lookupuseragent: Lookup a device with its user-agent string

A common use case is parsing web traffic logs or streaming HTTP traffic to augment data with device information. In those cases, not all HTTP headers may be present. If the device User-Agent header is available, here is a sample of the lookupuseragent input payload:

{
    "lookup_headers": {
        "User-Agent": "Mozilla/5.0 (Linux; Android 6.0; ASUS_Z017D Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.98 Mobile Safari/537.36"
    },
}

IMPORTANT NOTE: “User-Agent” header MUST be present in every request

Sending this payload using one of the RapidAPI code snippets returns this response (BASIC plan. More capabilities are available though the PRO, ULTRA and MEGA plans):

{ capabilities:
   { is_smarttv: 'false',
     is_smartphone: 'true',
     is_phone: 'true',
     brand_name: 'Asus',
     wurfl_id: 'asus_z017d_ver1',
     model_name: 'Z017D',
     is_mobile: 'true',
     marketing_name: 'Zenfone 3 ZE520KL',
     is_tablet: 'false',
     is_touchscreen: 'true',
     complete_device_name: 'Asus Z017D (Zenfone 3 ZE520KL)',
     is_full_desktop: 'false',
     form_factor: 'Smartphone',
     is_robot: 'false' },
  error: '' }

If an error occurs, the error field will contain the error message.
If you don’t need all the capabilities to be returned with the response, you can specify the desired capabilities in the input payload:

{
    "lookup_headers": {
        "User-Agent": "Mozilla/5.0 (Linux; Android 6.0; ASUS_Z017D Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.98 Mobile Safari/537.36"
    },
    "requested_caps":["brand_name"],
    "requested_vcaps":["form_factor"]
}

In this case, the response will be:

{ 
    capabilities:
   { 
         form_factor: 'Smartphone',
         wurfl_id: 'asus_z017d_ver1',
         brand_name: 'Asus' 
  },
    error: '' 
}

Endpoint lookupdeviceid: Lookup a device by its WURFL ID field

If you have previous experience with WURFL, you may already know that it is possible to query device capabilities using the WURFL ID (wurfl_id field). The WURFL ID is a unique identifier used internally by WURFL to identify a device profile. Different User-Agent strings may be mapped to the same WURFL ID by the API logic (this kind of reconciliation is integral part of the value provided by WURFL in many use cases).

To do it, you need to call the lookupdeviceid endpoint using a payload like the following:

{
    "wurfl_id": "asus_z017d_ver1"
}

Here is the response for the BASIC plan (more capabilities are available for PRO, ULTRA and MEGA plans):

{ capabilities:
   { is_smarttv: 'false',
     is_smartphone: 'true',
     is_phone: 'true',
     brand_name: 'Asus',
     wurfl_id: 'asus_z017d_ver1',
     model_name: 'Z017D',
     is_mobile: 'true',
     marketing_name: 'Zenfone 3 ZE520KL',
     is_tablet: 'false',
     is_touchscreen: 'true',
     complete_device_name: 'Asus Z017D (Zenfone 3 ZE520KL)',
     is_full_desktop: 'false',
     form_factor: 'Smartphone',
     is_robot: 'false' },
  error: '' }

As explained for the other endpoints (see above), you should specify the names of the static and virtual capabilities that you want through the requested_caps and requested_vcaps fields in the input payload.
If you use a wrong or empty wurfl_id, you’ll get an error message (error getting device using WURFL device ID: specified device is missing).

Demo Applications

In addition to the sample API usage for the different languages provided by RapidAPI, ScientiaMobile makes a few sample apps for all popular programming languages available at:

https://github.com/WURFL/RapidAPI

Capability list for each subscription plan

BASIC and PRO

wurfl_id
WURFL unique identifier for a device. Also used as input for endpoint lookupdeviceid.

brand_name - Static capability
Identifies Brand (example: Samsung)

complete_device_name - Virtual capability
Concatenates brand name, model name and marketing name (where available) of a device into a single string.

form_factor - Virtual capability
Returns the device’s form factor based on categorization provided by multiple capability tests

is_full_desktop - Virtual capability
This is just an ALIAS for ux_full_desktop.

is_mobile - Virtual capability
True if a device is wireless (WiFi, 3G, LTE etc.). Specifically a mobile phone or a tablet are considered as wireless devices, but a desktop PC or a laptop are not.

is_robot - Virtual capability
True if the HTTP Client is a Bot (robot, crawler or other programmable agent that stalks the web).

is_smartphone - Virtual capability
True if device conforms to ScientiaMobile’s definition of a Smartphone.

is_tablet - Static capability
True if a device is a tablet computer (iPad and similar, regardless of OS).

model_name - Static capability
Identifies Model (ex: N95)

is_phone - Virtual capability
True if a device is a mobile phone.

is_smarttv - Static capability
True if device is a SmartTV (GoogleTV, Boxee Box, AppleTV, etc.).

is_touchscreen - Virtual capability
True if the device has a touch screen. There is no control capability.

marketing_name - Static capability
In addition to Brand and Model, some devices have a marketing name (Eg. BlackBerry 8100 Pearl, Nokia 8800 Scirocco, Samsung M800 Instinct). Note: If the model and marketing names are the same for a device, this capability will return an empty value. Eg. Motorola Moto G8 Play.

ULTRA

All capabilities from PRO plus:

advertised_browser_version - Virtual capability
Infers the version of the browser based on user-agent string analysis (and possibly the analysis of other HTTP headers and WURFL capabilities).

advertised_device_os - Virtual capability
Infers the name of the Device OS based on user-agent string analysis (and possibly the analysis of other HTTP headers and WURFL capabilities).

advertised_device_os_version - Virtual capability
Infers the name of the Device OS Version based on user-agent string analysis (and possibly the analysis of other HTTP headers and WURFL capabilities).

device_os - Static capability
Identifies the device’s host operating system

max_image_height - Static capability
Maximum viewable (usable) height of an image expressed in logical or CSS pixels. This capability refers to the image when used in “mobile mode” (see explanation for max_image_width)

max_image_width - Static capability
Maximum viewable (usable) width of an image expressed in logical or CSS pixels. This capability refers to the image when used in “mobile mode”, i.e. when the page is served as XHTML MP, or it uses meta-tags such as “viewport”, “handheldfriendly”, “mobileoptimised” to disable “web rendering” and force a mobile user-experience. For example, iPhone 4 can render picture 640 pixel wide, but normally, pages are served assuming a 320 pixel wide screen.

resolution_height - Static capability
Screen height expressed in physical pixels.

resolution_width - Static capability
Screen width expressed in physical pixels.

advertised_app_name - Virtual capability
Returns the name of the application that generated the User-Agent or the HTTP request.

device_os_version - Static capability
Identifies the version of the device’s host operating system.

mobile_browser - Static capability
Identifies the device’s browser.

mobile_browser_version - Static capability
Identifies the version of the device’s browser

is_largescreen - Virtual capability
True if the device has a horizontal screen resolution greater than 320 pixels. Relies on the resolution_width capability.

MEGA

All the capabilities from the previous plans plus:

is_app - Virtual capability
True if the Requesting HTTP Client is an App or not.

manufacturer_name - Static capability
Name of the device’s manufacturer if it is different from the brand.

is_app_webview - Virtual capability
True if a HTTP request is from an app based webview.

is_ios - Virtual capability
True if device runs any version of iOS.

mobile_browser - Static capability
Identifies the device’s browser.

mobile_browser_version - Static capability
Identfies the version of the device’s browser

model_extra_info - Static capability
In addition to Brand and Model (and possibly a marketing name), some may be characterized by extra info (es: Nokia N95 8GB , Sharp 902SH Vodafone ).

physical_screen_height - Static capability
Screen height in millimeters.

physical_screen_width - Static capability
Screen width in millimeters.

ajax_support_javascript - Static capability
A device can be said Javascript enabled only if the following features are reliably supported: , confirm, access form elements (dynamically set/modify values), setTimeout, setInterval, document.location.

has_cellular_radio - Static capability
Device has cellular technology (most probably a phone, but not necessarily. May be a data-only device such as Kindle or Nokia N800).

is_android - Virtual capability
Checks if device runs any version of Android OS.

is_windows_phone - Virtual capability
True if device runs any version of Windows Phone OS. This virtual capability relies on the device_os (product_info group) capability.

preferred_markup - Static capability
This field identifies which markup is best supported by the device. This field is filled on personal experiences of our contributors and is used by the WALL library. Values for this capability look like: wml_1_1 , html_wi_imode_compact_generic and html_wi_oma_xhtmlmp_1_0 . Just like any other capability, you may override this value in the patch file.

viewport_width - Static capability
The method of specifying the viewport width. [empty] = not applicable; device_width_token = use string width=device-width as value ; width_equals_resolution_width = use (display) resolution_width; width_equals_max_image_width = use (display) max_image_width_width

is_wml_preferred - Virtual capability
True if the device is better served with WML. Capability relies on preferred_markup ( markup group).

is_xhtmlmp_preferred - Virtual capability
True if the device is better served with XHTML MP (Mobile Profile). Capability relies on preferred_markup (markup group).

Volgers: 0
Bronnen:
Productwebsite
API maker:
S
ScientiaMobile
wurfl-rapidapi-team
Log in om API te beoordelen
Beoordeling: 5 - Stemmen: 1