WhatIsMyBrowser.com API Integration Guide

Welcome

The WhatIsMyBrowser.com API provides an easy way to discover lots of useful things about web browser technology via API.

We provide a detailed API Specification, Sample Code, and world class support.

The integration document you are now reading accompanies the specs, sample code and support, taking you from the beginning all the way to being set up and integrated with the API.

Lets get started.

Sign Up

Before you can access the API, you need to register an account with us and get your API Key.

Once you have your API Key, you will send this as a HTTP header to show that your requests are authorised.

If you haven't already registered, you need to do so now. Go to the Sign up/Pricing page. You can sign up for whatever tier you need access to, without any cost (or even needing to put in your credit card details).

This gives you an excellent chance to fully test-drive the API (even on the higher access levels) before paying for it. If you continue using it, you will receive a notice requiring you to put your billing details in. There will only be an associated cost if you continue using it; you are free to leave at any time. If you fail to pay, your account will be lowered to the "Basic/Free" level at the end of the billing cycle.

Click the green Sign Up link underneath the plan you want to start out using (it's very easy to change your API plan later).

You are taken to a sign up form. Complete the form and submit it. We will send you an email containing a link to verify your email address. Once you click it, you will then be able to log in with your new account.

Accounts System

Once you are logged in, you will see the Accounts System landing page looking like this:

Screenshot of the Accounts System Logged In Landing Page

The Accounts System lets you do things like Change your Billing Details, Check your API Usage and Get your API Key.

Any time you need to change something relating to the API, this is where you need to go.

You can access it at: https://accounts.whatismybrowser.com/

Get your API Key

When you signed up with us, we automatically created an "Application" for you, which controls your API Key. To find that API key, simply click the Get your API Key link in the left column of the Accounts System. You will be taken to a page which shows you details about your application, including showing you your API Key.

Screenshot of the Application Page

Make a note of this API Key and keep it secret. It controls your access to the API. Anyone with a copy of it can access the API as you and use up your monthly quota.

Read the section on Authentication in this document for information about how to use this API Key.

Creating a new API Key

If your API Key is leaked, it will allow other people to perform API requests on your behalf.

If this happens, you need to generate a new API Key and stop using the old one.

To create a new API Key, click the big green button labeled Create new API Key below where your API Key is displayed in the Accounts System (follow the instructions above to get your API Key.

Monitor API usage

Keep an eye on your API account usage by looking at the Statistics Graph in the Accounts System.

To access it, click the Check API Usage link on the homepage of the Accounts system.

You can also visit the URL: https://accounts.whatismybrowser.com/buyer/stats

You will see a graph similar to the following one, showing your usage for the last month.

Screenshot of the Application Page

It will show you your usage for each API end-point seperately, including the number of hits per day. You can filter these end points by clicking the individual API Methods up the site to toggle their display.

Change your API Plan

It is easy to change your API plan with us. Billing is calculated daily, on a pro rata basis, so if you change part-way through a month, you will be billed accordingly.

To change your API plan, log in to the Accounts System: https://accounts.whatismybrowser.com/.

The Accounts System Homepage

Screenshot of the Accounts System Logged In Landing Page

From the logged in Home Page, click the Change your plan link in the right-hand column to edit your Application.

Edit Your Application

Screenshot of the Application Edit page

This will take you to a page which will let you edit your Application. One of the things you can edit is the plan which you are on.

At the top of the page, you will see the API plan that your account is currently using. Click the red "Review/Change" link next to it to see its features and choose another plan.

Choose your new plan

Screenshot of choosing a new plan

You can explore the different plan levels by clicking on the different levels up the side of the window. You will see the different features available on each plan. When you've found the plan you want to switch to, click the green "Change Plan" button at the bottom of the pop-over. If you want to cancel changing plans, just close the pop-over by clicking the X in the top right hand corner.

Your new plan choice will be accepted and the pop-over window will close. Your account is now on the new plan and you have immediate access to its features.

API Versioning

We want to make it easy for you to track the continuing development of the API. Like most software, we maintain a version number of the API which makes it easy to tell when there have been additions or changes to the API.

The API Versioning scheme we use is as follows:

Fragment Example Meaning
First element 2.1.2 The major version of the API. A change to this denotes a significant change to the core API. We have only changed this once - in the move from Version 1 to Version 2.
We have no plans for a Version 3 at the moment.
Second element 2.1.2 A change to this denotes a significant addition or change to the API - typically a new API end point.
Third element 2.1.2 A change to this denotes a minor addition or change to the API - perhaps a bug fix or a new response JSON key has been added (eg in the case of 2.1.1 and 2.1.2).

API Version number is for structure and functionality

Note that these API version numbers only concern the structure and functionality of the API, they have no bearing on the User Agent Parsing or the Software Version Number reporting.

The user agent parsing and software versions are continually checked and updated, and when they are updated: they do not affect the version number of the API.

The version number of the API will only increase when there are changes or additions to the API itself.

API Version History

View the WhatIsMyBrowser.com API Version History.

Get help

We are dedicated to providing you with the best support we can for the API.

We provide a detailed API Specification, Sample Code, FAQ and the Integration Guide you're reading now. If none of these can answer your problem, don't hesitate to get in touch with us; we're always happy to help.

You can contact us via the Accounts System -> New Message feature.
Alternatively, you can send us a message via our Main Website's Contact Form.

Please include as much detail as possible with your message as possible. We will reply as quickly as we can.

Common Elements of the API

Introduction

Each end-point of the API has a different objective, and so naturally they each accept different types of requests and provide different responses; however, there are a few elements which are common between them, so to save repeating ourselves, we describe them here.

Request and Response structure

The structure of URLs for the API is: https://api.whatismybrowser.com/api/v2/end-point

There are a number of different end points, depending on what you want the API to do for you. Refer to the individual sections of this guide for the end points you want to integrate with.

Request structure

The request structure varies by endpoint but the general idea is that if you're POST-ing something for us to process (eg. a user agent or batch of user agents), you'll send the POST body as valid JSON and we'll take it from there.

If it's a GET request, whatever you're "getting" from us will be somewhere in the URL.

Check the documentation for the end point in question.

Note that we also allow and fulfil OPTIONS requests - without affecting your API quota - so that Javascript based API requests work (most JS implementations seem to send a preflight OPTIONS request which fails if we don't allow OPTIONS).

Response structure

Each end point will return data relevant to itself, but there will also always be a result dictionary containing the result of your request. This is where you look to see whether your request worked. If there was a problem you'll find a description of the problem here too.

For example:

{ "some_kind_of_data_here": {...}, "result": { "code": "success", "message_code": "user_agent_parsed", "message": "The user agent was parsed successfully." } }

In this example, you can see that the message and message_code are from the User Agent Parse end point, but there is the common code key which will be either success or error.

Key Possible Values Description
code
  • success
  • error
A machine readable message that tells you whether your request was sent correctly and whether we handled it properly, or if there was some kind of problem on either end. Look at the message/message_code fields for more detail.
message Varies by end-point A human readable message that tells you specifically how your request was handled by the API.
message_code Varies by end-point A machine readable message that tells you specifically how your request was handled by the API.

The message fields

The message and message_code fields in the API response's result key will give you more detail about how your request was handled.

Generally speaking, if your request was successful, they will be something relating to your end point (eg. "The user agent was parsed successfully."). If there was some kind of problem the message will tell you more about the problem (eg. "No user_agents key was provided in the request"; or it may also be a more general kind of error: "No X-API-KEY header provided in the request".)

Message and Message Code

Inside the result key, the message key will contain a human readable message which is constructed for developers to read and get a better understanding of your request result, as well as this the message_code is specifically built for your software to inspect.

For example, your code can look for and handle scenarios like a message_code being usage_limit_exceeded, and know to not send any more API requests until the next month.

Your code should never inspect the contents of message and make decisions based on it. Instead: your code should look at message_code.

While we're always very careful... a human readable message string can still theoretically change - perhaps a minor punctuation correction, or meaningful clarification...

However message_code is specifically built to never change, so if your code checks for certain values, you can be assured that it will always work the same way.

Common message_code values

The following table doesn't show all of the message codes which the API can return; these are the ones that are common between all end points. End points will also return ones specific to them. Make sure to read the documentation for those end points as well.

Possible message_code when code is error

message_code Description
api_system_error Some kind of Server Side Error (500) has occurred.
invalid_api_version Version 2 of the API is the latest version. So if you try to access an end point starting with /api/v3/ or higher you will get this error.
invalid_http_request_method Your request was sent with the wrong method: Perhaps you sent it as a GET instead of a POST. (or maybe vice-versa)
missing_api_authentication Your request didn't contain the X-API-KEY.
Refer to Debugging Authentication.
usage_limit_exceeded Your account has gone over your monthly quota for this end point.
api_authentication_invalid The API Key sent in X-API-KEY was incorrect.
Maybe you generated a new one? Get your API Key.
endpoint_not_available_for_this_api_version Version 1 of the API has been deprecated (but not discontinued). However new end points will not be back-ported to Version 1.
You are trying to access one of the new end points on an older version of the API.
endpoint_not_available_for_your_plan You tried to access an API End Point that your plan doesn't have access to. Change your API Plan.
invalid_end_point 404 End Point not found. Check the URL.
invalid_json We couldn't decode valid JSON from your request.

HTTP Status Codes

As well as returning result messages and codes, we also return meaningful HTTP Status Codes.

Status Code Name Description
200 Success We handled your request successfully.
400 Bad request There was something wrong with your request.
Check the "message" fields for more information.
401 Invalid API Key Your API Key is wrong. Get your API Key.
403 Quota exceeded You have gone over your monthly limit. Monitor API usage.
404 Not Found The End Point URL you requested was incorrect.
405 Wrong method You did something like send a GET instead of a POST (or maybe a POST instead of a GET)
500 Server Error We've had some kind of error on our end.

TLS Security

You can access the API via either the http or https protocol.

We recommend using https.

Authentication

Authenticating your API requests is done by sending a HTTP Header called: X-API-KEY with the value being your API Key which you got by following the Get your API Key instructions.

Here are some relevant snippits of sample code showing this to give you the idea.

Authentication example using Python & the Requests Module

import requests headers = { 'X-API-KEY': config.api_key, } result = requests.post(api_url, data=json.dumps(post_data), headers=headers)

Authentication example using PHP & the cURL Module

$headers = [ 'X-API-KEY: '.$api_key, ]; curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);

As per the HTTP RFC 2616, header field names are not case sensitive, so it doesn't matter if you send the header as X-API-KEY or x-api-key.

For examples in more programming languages, please look at our Sample Code.

Authentication Issues and Errors

Missing API Key

If you don't send the your API Key in the X-API-KEY HTTP header, you will receive a response like:

{ "result": { "code": "error", "message": "No X-API-KEY header was provided in the request", "message_code": "missing_api_authentication" } }

This can happen for a number of reasons, check out the section on Debugging Authentication Problems.

Invalid API Key

If you send an incorrect X-API-KEY, you will receive a response like:

{ "result": { "code": "error", "message": "user key QWERTYIOPSDFJLKJ is invalid", "message_code": "api_authentication_invalid" } }

Note that the API Key that you sent through is included in the result message; so that you can confirm that you are sending the key that you intend to.

This error can occur if you generate a new API key but don't update your code to send the new API key through.

If you're stuck, check out the section on Debugging Authentication Problems.

No access to end point

If you send a valid API Key but your account's plan does not have access to the specified end point, you will receive a response like:

{ "result": { "code": "error", "message": "The plan your account is on (basic) does not have permission to access this API endpoint. Please upgrade to a plan which grants you access.", "message_code": "endpoint_not_available_for_your_plan" } }

You will get this kind of response if you do something like try to access the User Agent Batch Parser on the Basic plan.

If you want permission to access to the end point you're trying to use, you can upgrade your API Plan.

Usage Limit Exceeded

If you send a valid API key but your account has gone over it's monthly limit for this end point, you will receive a response like:

{ "result": { "code": "error", "message": "Your account has gone over its limit for this month. Please consider upgrading your plan.", "message_code": "usage_limit_exceeded" } }

Note that end points are metered independently of each other; so you might have exceeded the limit of one end point but can still use other ones.

You can monitor your account usage in the Accounts System -> Check API Usage.

We will send you warning emails when you are at 90% and 100% of your limits.

User Agent Parsing

Introduction

The User Agent Parse end point allows you to send a User Agent String and received a detailed response back, describing as much as we can tell you about it in individual fields.

The User Agent Parse end point is designed for parsing individual user agents, one at a time; if you need to parse a large batch of user agents then you should look at the User Agent Batch Parsing end point.

User Agent Parse - Request and Response

Making an API request to the User Agent Parse end point is quite straightforward.

Request

End Point URL https://api.whatismybrowser.com/api/v2/user_agent_parse
HTTP Method POST
HTTP POST Body Send the user agent in a JSON dict; in a key called user_agent

HTTP POST Body

To send a user agent string to be parsed, you simply need to put it in a JSON key named user_agent and POST it to the API.

{ "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36" }

Response

This is an example response (with line breaks to make it readable) containing all parse fields for the user agent given in the example request (above).

{ "parse": { "simple_software_string": "Chrome 64 on Mac OS X (Mavericks)", "simple_sub_description_string": null, "simple_operating_platform_string": null, "software": "Chrome 64" "software_name": "Chrome", "software_name_code": "chrome", "software_version": "64", "software_version_full": [ "64", "0", "3282", "140" ], "operating_system": "Mac OS X (Mavericks)", "operating_system_name": "Mac OS X", "operating_system_name_code": "mac-os-x", "operating_system_version": "Mavericks", "operating_system_version_full": [ "10", "9", "5" ], "operating_system_flavour_code": null, "operating_system_flavour": null, "operating_system_frameworks": [], "operating_platform": null, "operating_platform_code": null, "operating_platform_vendor_name": null, "software_type": "browser", "software_sub_type": "web-browser", "hardware_type": "computer", "hardware_sub_type": null, "hardware_sub_sub_type": null, "layout_engine_name": "Blink", "layout_engine_version": [], "extra_info": {}, "extra_info_dict": {}, "capabilities": [], "detected_addons": [], "is_abusive": false, "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36", }, "version_check": { "is_checkable": true, "is_up_to_date": true, "latest_version": [ "64", "0", "3282", "140" ], "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/chrome", "download_url": "https://www.google.com/chrome/" }, "result": { "code": "success", "message": "The user agent was parsed successfully.", "message_code": "user_agent_parsed" } }

Field Definitions

This is a detailed description of the parts of a user agent parse response.

The JSON in a successful response will contain parse and result dictionaries. If you are on any of the paid plans (Standard, Pro or Enterprise) you will also get a version_check dictionary which contains information about whether their software is up to date or not.

parse key elements

These are the fields you will find in a user agent parse response under the parse key.

The availablility of some of the user agent parse fields depends on which API plan your account has access to. If you don't have access, they will not appear in the response. It is easy to change your API plan.

Field Name Plan Example Description
simple_software_string
  • Basic
  • Std
  • Pro
  • Ent
Chrome 64 on Mac OS X (Mavericks) A nice description of the Software and Operating System (or Platform - when possible and when there’s not also an Operating System). Very human readable; intended to be shown to end-users.
simple_sub_description_string
  • Basic
  • Std
  • Pro
  • Ent
Internet Explorer 7 Compatibility View A nice sub-description of the software and/or platform being used. It won’t always have a value, but when it does, it always compliments or further explains the simple_software_string.
simple_operating_platform_string
  • Basic
  • Std
  • Pro
  • Ent
Samsung Galaxy Tab S2 9.7" (SM-T817R4) A nice description of whatever can be detected as the hardware platform. While the various parts of this string (operating platform, operating platform vendor name, operating platform code etc) will also be available in their individual respective fields, this field combines them in a readable form depending on which values are actually available.
software
  • Basic
  • Std
  • Pro
  • Ent
Chrome 64 The software name and a human readable / summarised version of the software (eg Chrome 64.0.3282.140 will be summarised here as "Chrome 64")
software_name
  • Basic
  • Std
  • Pro
  • Ent
Chrome The name of the software sending the request
software_name_code
  • Basic
  • Std
  • Pro
  • Ent
chrome A “slugged” version of the software_name - removed special characters, removed spaces, lower case, combined with single hyphens. Useful for referring to in your code/database.
software_version
  • Basic
  • Std
  • Pro
  • Ent
64 A "human readable"/simplified version of the version of the software being used. Note that it is a string, not an integer (to accomodate values like “3.8”).
software_version_full
  • Basic
  • Std
  • Pro
  • Ent
["64", "0", "3282", "140"] The full version of the software making the request
operating_system
  • Basic
  • Std
  • Pro
  • Ent
Mac OS X (Mavericks) A nice, readable description of the Operating System and major version (if possible)
operating_system_name
  • Basic
  • Std
  • Pro
  • Ent
Mac OS X The name of the Operating System
operating_system_version
  • Basic
  • Std
  • Pro
  • Ent
Mavericks A “readable” version description of the Operating System - eg for OSX it might say "Mavericks" (instead of “10.9.5”) for Windows it might say 10 (instead of "NT 10.0")
operating_system_version_full
  • Basic
  • Std
  • Pro
  • Ent
["10", "9", "5"] The detailed version number for the Operating System (For Windows it might be ["NT 6.1"])
operating_system_name_code
  • Basic
  • Std
  • Pro
  • Ent
mac-os-x A "slugged" version of the operating_system_name. Useful for referring to in your code/database.
operating_system_flavour
  • Basic
  • Std
  • Pro
  • Ent
Debian Sometimes it’s even possible to determine a flavour/distribution/variant of an operating system. This allows (for example) all the different types of Linux to just be "Linux" and not "Debian Linux"… to group them all together in your database or code, yet still make a distinction between the "flavours" of Linux when possible/desired.
operating_system_flavour_code
  • Basic
  • Std
  • Pro
  • Ent
debian A slugged version of operating_system_flavour
operating_platform
  • Pro
  • Ent
Galaxy Tab S2 9.7" A nice, readable description of the Operating Platform
operating_platform_code
  • Pro
  • Ent
SM-T817R4 The product number/code number or other technical description of the operating platform.
operating_platform_vendor_name
  • Pro
  • Ent
Samsung The name of the vendor/manufacturer of the platform
operating_system_frameworks
  • Pro
  • Ent
[{ "code": "microsoft-dotnet", "name": "Microsoft .Net", "versions": [ { "simple": "4.0", "full": [ "4", "0E" ] }, { "simple": "4.0", "full": [ "4", "0C" ] }, { "simple": "3.5", "full": [ "3", "5", "30729" ] } ] }]
This field was designed to hold a detailed breakdown of all the Microsoft DotNet frameworks contained in a user-agent (because some user agents contain more than five or six of them!)
extra_info_dict
  • Pro
  • Ent
{ "Dalvik library version": "1.6.0", "System Build": "SU6-7.3" }
A dictionary of various other things which can be discovered from the user agent. If a software library can be detected, it will be found here.
extra_info
  • Pro
  • Ent
{ "10": [ "Internet Explorer 7 Compatibility View" ], "20": [ "Possibly running on Windows Server 2008", "Tablet PC" ] }
This contains various bits of information that can be gathered from the user agent but which doesn't fit in to any of the other API fields. It is a dictionary of lists; The ones in the 10 key are considered more important or interesting than the rest. They are the ones which are combined to make up the "simple_sub_description_string". Elements in the 20 element are of "medium" level significance. 30 has been reserved for "low" level significance.
capabilities
  • Pro
  • Ent
[ "Touch capability", "Silk Accelerated", "MIDP v2.1" ]
Various capabilities which have been detected
detected_addons
  • Pro
  • Ent
[ "Yahoo Toolbar v7.3.0", "Windows Live Messenger v15.4", "ImageShack Toolbar v4.3" ]
Addons/Extensions which can be detected via the user agent. This section can only show addons which announce themselves in the user agent.
layout_engine_name
  • Pro
  • Ent
WebKit The name of the HTML Layout Engine
layout_engine_version
  • Pro
  • Ent
[ "537", "36" ]
The version number list of the HTML Layout Engine
software_type
  • Std
  • Pro
  • Ent
It can be one of these values:
  • browser
  • bot
  • application
A "top-level" description of the type of software making the request.
This allows us to broadly categorise software into these three major types of user agent, and then also be very specific about the type of software (via the software_sub_type field)
A browser implies a certain level of interactivity - the user is most likely directly browsing your site.
A bot seems to be some kind of automated system, crawling, analysing, monitoring your site.
An application is for the things which don’t fit into either of those two other categories - maybe its a billboard, or perhaps a download helper.
software_sub_type
  • Std
  • Pro
  • Ent
Possible values when software_type is browser:
  • web-browser
  • in-app-browser
  • offline-browser
  • rss-reader
  • ua-anonymizer
  • email-client
Possible values when software_type is bot:
  • crawler
  • analyser
  • tool
  • security-analyser
  • site-monitor
  • feed-fetcher
Possible values when software_type is application:
  • billboard
  • download-helper
  • software-library
  • proxy
  • media-player
The "sub-type" of the software - If you combine it with software_type, you will get a clear picture of the software making the request. These are the sub-types for the three software_type values.
hardware_type
  • Std
  • Pro
  • Ent
It can be one of these values:
  • mobile
  • computer
  • appliance
  • large-screen
  • server
  • vehicle
A “top-level” description of the type of hardware the software making the request is using.
hardware_sub_type
  • Std
  • Pro
  • Ent
Possible values when hardware_type is mobile:
  • phone
  • tablet
  • phablet
  • ebook-reader
  • handheld-game
  • music-player
  • pda
  • wearable
Possible values when hardware_type is computer:
  • desktop
  • portable
Possible values when hardware_type is appliance:
  • refrigerator
  • toaster
  • lightbulb
  • security-camera
Possible values when hardware_type is large-screen:
  • tv
  • billboard
  • media-player
  • game-console
Possible values when hardware_type is large-screen:

None - Server doesn't have a hardware sub type

Possible values when hardware_type is vehicle:
  • car
The “sub-type” of the hardware - If you combine it with hardware_type, you will get a clear picture of the hardware the software making the request is running on. These are the sub-types for the seven hardware_type values.
Note that it’s not always possible to determine one of these hardware_sub_type values - for example most user agents on a computer look the same whether they’re on a desktop or a portable laptop...
hardware_sub_sub_type
  • Std
  • Pro
  • Ent
Possible values when hardware_sub_type is wearable:
  • watch
  • glasses
  • vr
In some cases, it’s possible to determine a third-level of specificity about the hardware being used (for now, this is only possible on mobile -> wearable devices)
is_abusive
  • Std
  • Pro
  • Ent
  • true
  • false
Whether or not this user agent contains a fragment which could be considered abusive/malicious. Often criminals will try to put SQL Injection attempts or XSS into user agents because some sites don’t handle user agents properly.
user_agent
  • Basic
  • Std
  • Pro
  • Ent
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 The user agent which was sent to the API and parsed is also returned in the response, allowing you to confirm/debug exactly what we received.

version_check key elements

These are the fields you will find in a user agent parse response under the version_check key.

The version_check key is only available for paid plans (Standard, Pro or Enterprise). If you need access to it it is easy to change your API plan.

Field Name Plan Example Description
is_checkable
  • Std
  • Pro
  • Ent
  • true
  • false
Whether or not the API is able to check if this software is up to date. Version Checking exists for Chrome, Safari, Edge, Firefox, Internet Explorer and Opera.
is_up_to_date
  • Std
  • Pro
  • Ent
  • true
  • false
Whether or not the software is considered up to date. Will not exist in the response if is_checkable is false.
latest_version
  • Std
  • Pro
  • Ent
["64", "0", "3282", "140"] If we provide version checking for this browser/software, then latest_version will contain what we consider the latest version. This is helpful for displaying messages like 'You should upgrade to version XYZ' to your users.
update_url
  • Std
  • Pro
  • Ent
https://www.whatismybrowser.com/guides/how-to-update-your-browser/chrome URL of webpage which will give instructions to upgrade their web browser (this will be present for only some browsers)
download_url
  • Std
  • Pro
  • Ent
https://www.google.com/chrome/ URL of a webpage where your user can download the browser from (this will be present for only some browsers)

result key elements

Remember: there are some message_code values which are common to all end points (eg api_authentication_invalid) - they are described here.

The following tables describe message_code values which are unique to the User Agent Parse end point.

Possible message_code when code is success

message_code Description
user_agent_parsed The user agent was parsed successfully.

Possible message_code when code is error

message_code Description
no_user_agent No user_agent provided in the request. You sent valid JSON but we didn't see the user_agent key in it.
invalid_user_agent_type You sent a user_agent value in the JSON but it wasn't a string/unicode (maybe it was a list or an int?).

User Agent Batch Parsing

Introduction

The original User Agent Parse end point was created for parsing individual user agents very quickly. But if you've got a large batch of user agents stored in a database or set of log files, it makes much more sense to send those user agents through in a large batch instead of making a different HTTP request for each user agent. This is where the user agent batch parsing end point comes in handy.

The maximum batch size is 500 user agents per request.

User Agent Parse Batch - Request and Response

Making an API request to the User Agent Parse Batch end point is quite straightforward.

Request

End Point URL https://api.whatismybrowser.com/api/v2/user_agent_parse_batch
HTTP Method POST
HTTP POST Body Send your batch of user agents in a JSON dictionary key called user_agents. You need a unique key in user_agents for each individual user agent, so that you can match up the parse results in the response.

HTTP POST Body

It doesn't matter what the individual keys of user_agents are, as long as they are unique to your HTTP request (it also doesn't matter if you reuse keys in different requests). If your batch of user agents are coming from a database, you might use the primary key for each user agent. As per the JSON specification, dictionaries can't be relied on to have a certain ordering - you can't assume that the tenth parse result will correspond with the tenth user agent you sent through, so the unique key is necessary for you to be able to match user agent parse results back to what you sent through.

If you have no need to match them back to an original record (eg. to update a database) and instead are just making a report about each of your user agents, you can just use a number and increment it for each one you send through - and then disregard it in the response and just loop over each result in parses.

"user_agents": { "1": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36", "2": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36" }

Response

This is an example response (with line breaks to make it readable) for the user agent batch given in the example request (above).

{ "parses": { "1": { "parse": { "hardware_type": "computer", "operating_system_name": "Mac OS X", "software_sub_type": "web-browser", "operating_system_version": "Yosemite", "simple_sub_description_string": null, "software_type": "browser", "hardware_sub_sub_type": null, "extra_info": {}, "software_version_full": [ "44", "0", "2403", "155" ], "software_name_code": "chrome", "layout_engine_name": "Blink", "capabilities": [], "operating_system_flavour_code": null, "detected_addons": [], "operating_system_flavour": null, "operating_system_frameworks": [], "hardware_sub_type": null, "software_name": "Chrome", "software_version": "44", "simple_operating_platform_string": null, "operating_platform_vendor_name": null, "operating_platform": null, "extra_info_dict": {}, "is_abusive": false, "operating_system": "Mac OS X (Yosemite)", "operating_system_version_full": [ "10", "10", "4" ], "operating_platform_code": null, "operating_system_name_code": "mac-os-x", "layout_engine_version": [], "simple_software_string": "Chrome 44 on Mac OS X (Yosemite)", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36", "software": "Chrome 44" }, "version_check": { "latest_version": [ "64", "0", "3282", "119" ], "is_checkable": true, "is_up_to_date": false, "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/chrome", "download_url": "https://www.google.com/chrome/" }, "result": { "message": "The user agent was parsed successfully.", "code": "success", "message_code": "user_agent_parsed" } }, "2": { "parse": { "hardware_type": "computer", "operating_system_name": "Linux", "software_sub_type": "web-browser", "operating_system_version": null, "simple_sub_description_string": null, "software_type": "browser", "hardware_sub_sub_type": null, "extra_info": {}, "software_version_full": [ "42", "0", "2311", "135" ], "software_name_code": "chrome", "layout_engine_name": "Blink", "capabilities": [], "operating_system_flavour_code": null, "detected_addons": [], "operating_system_flavour": null, "operating_system_frameworks": [], "hardware_sub_type": null, "software_name": "Chrome", "software_version": "42", "simple_operating_platform_string": null, "operating_platform_vendor_name": null, "operating_platform": null, "extra_info_dict": { "Hardware Architecture": "x64" }, "is_abusive": false, "operating_system": "Linux", "operating_system_version_full": [], "operating_platform_code": null, "operating_system_name_code": "linux", "layout_engine_version": [], "simple_software_string": "Chrome 42 on Linux", "user_agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36", "software": "Chrome 42" }, "version_check": { "latest_version": [ "64", "0", "3282", "119" ], "is_checkable": true, "is_up_to_date": false, "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/chrome", "download_url": "https://www.google.com/chrome/" }, "result": { "message": "The user agent was parsed successfully.", "code": "success", "message_code": "user_agent_parsed" } } } "parse_stats": { "total": 500, "success": 500, "error": 0 }, "result": { "message": "This batch of user agents was processed successfully. Check `parse_stats` for details.", "code": "success", "message_code": "user_agents_batch_processed" } }

Field Definitions

This is a detailed description of the parts of a user agent parse batch response.

The JSON in a successful response will contain parses, parse_stats and result dictionaries.

parses key elements

The parses element is a dictionary - the keys are the unique keys you sent through in your user_agents dictionary. The contents of each parses element follow exactly the same rules as an individual user agent parse request. Each element will have it's own result key, just like an individual parse response, and if your account has access to version checking (ie. It's on a Standard, Pro or Enterprise plan), you will also get a version_check dictionary.

Go through each user agent in parses and match it's key with whatever system you used to create the keys with in the first place - perhaps database "primary keys".

parse_stats key elements

To give you some summary information about your batch request, parse_stats contains a summary of the batch which was just processed.

total The total number of user agents in the parses element. It should match the number of user agents you sent through.
success Number of successful parses - even if a user agent couldn't be detected or was considered abusive, it will still be "successful" - it just means that there wasn't a problem with the actual request you made.
error Number of failed parses - perhaps a user agent in parses wasn't a unicode/string or there was some other core issue.

result key elements

Remember: there are some message_code values which are common to all end points (eg api_authentication_invalid) - they are described here.

The following tables describe message_code values which are unique to the User Agent Parse Batch end point.

Possible message_code when code is success

message_code Description
user_agents_batch_processed The batch of user agents was parsed successfully.

Possible message_code when code is error

message_code Description
no_user_agents No user_agents provided in the request. You sent valid JSON but we didn't see the user_agents key in it.
invalid_user_agents_type You sent a user_agents value in the JSON but it wasn't a dict (maybe it was a string or a list?).
user_agents_was_empty You sent a user_agents value but it didn't have any user agents in it.
too_many_user_agents You sent too many user agents in the batch. The limit is 500.

Software Version Numbers

Introduction

The Software Version Numbers end point lets you get the latest version numbers of popular web browsers and browser plugins via an API.

The standard/default option is to simply get all the version numbers we provide; you can then grab the ones you need from there and do whatever you need to with them (store them, etc). This is perfect if you need to get more than one version number from us - just get them all in one hit!

But if you really do just need the version numbers for a single bit of software (browser or plugin), then you can limit what gets returned in the response.

Software Version Numbers - Request and Response

Making an API request to the Software Version Numbers end point is quite straightforward.

Request

End Point URL https://api.whatismybrowser.com/api/v2/software_version_numbers/software_name_code
HTTP Method GET
URL element There is a software_name_code element in the URL. This specifies what to return version numbers for.

URL element - software_name_code

You can use different values for the software_name_code URL element depending on what you need to do.

The "standard" or "default" thing to do would be to set it to all, so that you get all the version numbers we provide - you can then process the response extracting some or all of the software version numbers you need.

End point URL - requesting all version numbers:

https://api.whatismybrowser.com/api/v2/software_version_numbers/all

Even if you were only interested in the latest version numbers for Chrome and Firefox, it would still make sense to request all version numbers, and then just look for those two elements in the response. Doing it this way requires one HTTP request and one quota hit, instead of two HTTP requests and two quota hits.

If you really require version numbers for just one software package, you can request it like this:

End point URL - requesting version numbers for just one software package:

Instead of putting all in the url, use a the software name code that you want version data for. For example, requesting version data for chrome:

https://api.whatismybrowser.com/api/v2/software_version_numbers/chrome

The software name codes you can request version data for are:

  • chrome
  • firefox
  • edge
  • internet-explorer
  • safari
  • opera
  • flash
  • java

Response

As discussed, you can either request version data for "all" software packages, or version data for just one specific software package by changing your request URL.

What you request will control what is returned in the response.

Requesting version numbers for all software

You would send your request to the URL:

https://api.whatismybrowser.com/api/v2/software_version_numbers/all

And the response would have this structure:

{ "version_data": { "chrome": { "windows": { "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/chrome", "latest_version": [ "64", "0", "3282", "168" ], "download_url": "https://www.google.com/chrome/" }, "macos": { "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/chrome", "latest_version": [ "64", "0", "3282", "167" ], "download_url": "https://www.google.com/chrome/" }, "ios": { "latest_version": [ "64", "0", "3282", "112" ], "download_url": "https://itunes.apple.com/app/chrome-web-browser-by-google/id535886823" }, "android": { "latest_version": [ "64", "0", "3282", "137" ], "download_url": "https://play.google.com/store/apps/details?id=com.android.chrome" }, "linux": { "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/chrome", "latest_version": [ "64", "0", "3282", "167" ], "download_url": "https://www.google.com/chrome/" } }, "firefox": { "standard": { "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/firefox", "latest_version": [ "58", "0", "2" ], "download_url": "https://www.mozilla.org/firefox/new/" } }, "firefox-esr": { "standard": { "latest_version": [ "52", "6", "0" ], "download_url": "https://www.mozilla.org/en-US/firefox/organizations/all/" } }, "opera": { "standard": { "latest_version": [ "51", "0", "2830", "26" ], "download_url": "https://www.opera.com/" } }, "flash": { "android": { "update": "81", "latest_version": [ "11", "1", "115" ] }, "standard": { "latest_version": [ "28", "0", "0" ], "update": "161", "download_url": "https://get.adobe.com/flashplayer/" } }, "internet-explorer": { "internet-explorer-xp": { "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/internet-explorer", "latest_version": [ "8" ], "download_url": "https://windows.microsoft.com/internet-explorer/download-ie" }, "internet-explorer-windows-7": { "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/internet-explorer", "latest_version": [ "11" ], "download_url": "https://windows.microsoft.com/internet-explorer/download-ie" }, "internet-explorer-windows-8": { "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/internet-explorer", "latest_version": [ "10" ], "download_url": "https://windows.microsoft.com/internet-explorer/download-ie" }, "internet-explorer": { "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/internet-explorer", "latest_version": [ "11" ], "download_url": "https://windows.microsoft.com/internet-explorer/download-ie" }, "internet-explorer-windows-8-1": { "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/internet-explorer", "latest_version": [ "11" ], "download_url": "https://windows.microsoft.com/internet-explorer/download-ie" }, "internet-explorer-vista": { "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/internet-explorer", "latest_version": [ "9" ], "download_url": "https://windows.microsoft.com/internet-explorer/download-ie" }, "internet-explorer-windows-10": { "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/internet-explorer", "latest_version": [ "11" ], "download_url": "https://windows.microsoft.com/internet-explorer/download-ie" } }, "edge": { "xbox-one": { "latest_version": [ "40", "15063", "0", "0" ] }, "windows-10": { "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/edge", "latest_version": [ "41", "16299", "15", "0" ] }, "windows-10-mobile": { "latest_version": [ "38", "14393", "693", "0" ] } }, "safari": { "macos": { "update_url": "https://www.whatismybrowser.com/guides/how-to-update-your-browser/safari", "latest_version": [ "11", "0", "3" ] }, "ios": { "latest_version": [ "11", "1", "1" ] } }, "java": { "standard": { "latest_version": [ "8" ], "update": "161", "download_url": "https://java.com/download/" } } }, "result": { "message": "Software Version Numbers were returned successfully", "code": "success", "message_code": "software_version_numbers_returned" } }

Requesting version numbers for a specific software name code

This is an example response (with line breaks to make it readable) for requesting version numbers for just opera.

You would send your request to the URL:

https://api.whatismybrowser.com/api/v2/software_version_numbers/opera

And the response would have this structure:

{ "version_data": { "opera": { "standard": { "latest_version": [ "50", "0", "2762", "67" ], "download_url": "https://www.opera.com/" } } }, "result": { "message": "Software Version Numbers were returned successfully", "code": "success", "message_code": "software_version_numbers_returned" } }

Field Definitions

This is a detailed description of the parts of a software version numbers response.

The JSON in a successful response will contain version_data and result dictionaries.

version_data key elements

Each key in the version_data dictionary corresponds to a different software package, and contains the software version number/s for it.

If you send a request for "all, the keys which will exist under version_data are:

  • chrome
  • firefox
  • edge
  • internet-explorer
  • safari
  • opera
  • flash
  • java
If you send a request for one of the above "software name codes", the response will contain version numbers for just that software, under that key in version_data.

Each one of these "software name codes" then contains one or more "streams". For example, we provide version data for the latest version of chrome for five streams: windows, macos, linux, android and ios.

Elements for each stream in a software_name_code key

latest_version is the only element guaranteed to be present; all other fields will appear depending on the individual software package.

latest_version Contains a list of version number fragments.
update Only exists for flash and java. This is a number additional to the latest_version - it's an "update" or "revision" number. eg. Sometimes there is a Flash update without Adobe releasing a new "version" - the update value increases but the version number stays the same.
update_url A URL giving instructions on how to update this software to the latest version. It will be a link to one of our tutorials showing you how to update your web browser. You can direct your user there to get further help.
download_url The software vendor's download page - where your user can download the latest version from.

result key elements

Remember: there are some message_code values which are common to all end points (eg api_authentication_invalid) - they are described here.

Possible message_code when code is success

message_code Description
software_version_numbers_returned Software version number/s were returned. You don't need to worry about the plurality of "numbers" vs "number" in the code - this will always be "software_version_numbers_returned" - even if you requested a single "software name code", or there was only one stream.

Possible message_code when code is error

message_code Description
invalid_software_name_code You didn't provide a valid software_name_code. It either needs to be all, or one of the software_name_codes.

Debugging

Introduction

Have you run into a problem? Here are some tips to get you on the right track.

If there's anything you think is missing here, or if you need further help, refer to our Get Help and we'll sort you out!

Debugging Authentication Problems

The two message_code errors relating to authentication which can occur are: missing_api_authentication and api_authentication_invalid.

  • missing_api_authentication


    This happens when - for some reason - our API servers don't see the X-API-KEY HTTP Header in your request.

    Common reasons for this are:

    • The header is misspelled in your request
    • Your code isn't sending it properly (it's not actually putting it in the request)
    • Your server is behind some kind of proxy/gateway which is stripping that header out

  • api_authentication_invalid


    This happens when the API key you send in the HTTP Header is incorrect.

    Common reasons for this are:

A good way of checking to see exactly what your system is sending in its API requests is a handy website called RequestBin. Read our section on Debugging using RequestBin for instructions on how to use it.

Debugging JSON Problems

There are two main classes of JSON problems that you may encounter when using the API:

Requests containing invalid JSON

These kinds of errors - where the API returns a result -> message_code of invalid_json - occur mainly when developers try to construct the JSON themselves by hand - as opposed to using whatever JSON library their programming language provides to do the heavy-lifting for you.

For example, hand-crafting JSON in python (don't do this!):

import requests user_agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36" hand_made_json = '{"user_agent": "%s"}' % user_agent result = requests.post(api_url, data=hand_made_json, headers=headers)

In the fourth line of the example above, you can see the actual JSON string being constructed by hand: '{"user_agent": "%s"}' % user_agent.

That example does actually work; but it's very prone to problems.

You become responsible for getting the JSON format perfect; if you miss a semi-colon:

hand_made_json = '{"user_agent" "%s"}' % user_agent

you'll get:

{ "result": { "message": "Expecting : delimiter: line 1 column 15 (char 14)", "code": "error", "message_code": "invalid_json" } }

This isn't likely to happen on simple examples, but when you start to get into the batch processing requests and other more complicated requests, problems become more likely. Since all modern languages provide some kind of in-built JSON library, you should just take advantage of it and make your own life easier.

From a security/integrity perspective, it's also a bad idea to roll your own JSON strings. The "hand made" example above is vulnerable to injection issues (what if the user agent had a " in it? It would break your JSON.) And so you have to start to worry about escaping values... and suddenly things just got a lot more complicated for you.

Instead, (in the case of Python), you should use the inbuilt json module, which provides all of these niceties, making it much, much easier for you to generate JSON that won't be syntactically wrong (and which is also automatically escaped, etc).

For example, properly creating JSON in python:

import requests import json user_agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36" post_data = { 'user_agent': user_agent, } result = requests.post(api_url, data=json.dumps(post_data), headers=headers)

On line 5, a normal Python dictionary is created, using "user_agent" as the only key. Then on the last line, where the request is sent, json.dumps() is used to automatically convert that python dictionary into a JSON dictionary, where escaping and other things are safely considered.

If you use your language's inbuilt JSON functions, you are much more likely to prevent invalid_json errors.

Incorrect JSON structure

Sending the wrong JSON structure in your request will result in errors like:

{ "result": { "message": "There was a problem extracting the user agent field from your request. There was no `user_agent` key in the JSON you sent.", "code": "error", "message_code": "no_user_agent" } }

This is occuring because the JSON structure didn't look like:

{ "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36" }

Maybe "user_agents" was misspelled:

{ "usr_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36" }

and so we couldn't find it in your request.

Maybe it was nested under something else by mistake:

[{ "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36" }]

And so, while both of those examples are syntactically correct JSON, they will result in a no_user_agent message_code because we couldn't find user_agent where it was supposed to be.

If you get an error like this, make sure that you are sending the JSON with the correct structure.

You can use RequestBin and look at the POST BODY section to see what you've sent through. If it isn't valid JSON (use a JSON validator like the one provided here to ensure that what you're sending is valid JSON and conforms to the structure we expect.

Debugging API requests with RequestBin

A great tool for debugging problems with the API is a website called RequestBin. It lets you send any kind of HTTP request to your own special location on their site, where they then give you a detailed read-out of exactly what you sent; including headers, parameters and request body. This shows you exactly what your server is transmitting (or not transmitting) and it can be an invaluable tool in locating problems.

1. Create a RequestBin:

  1. Visit their homepage: https://requestb.in/
  2. Complete the Captcha
  3. We recommend you tick the Private (only viewable from this browser) checkbox
  4. Click the green Create a RequestBin button.
The site then takes you to a new page which shows you your unique Bin URL at the top of the page in a large font.

Screenshot of the top of a new RequestBin page

2. Use your RequestBin:

In the code that you're debugging; change the request URL from https://api.whatismybrowser.com/api/v2/... to the url at the top of your RequestBin page (eg. https://requestb.in/abcd1234 ).

So now, when you run your code, instead of sending the request to the WhatIsMyBrowser.com API servers, it sends that request to your unique RequestBin URL.

RequestBin will now be expecting your request, so when you execute your code, it captures the request and shows you exactly what you sent.

3. Inspect your RequestBin

After you've triggered your code to send its request to the RequestBin you've just created, press Refresh in your browser to reload the "inspect" page for your RequestBin. You should see a read-out showing information about what you just sent.

If you send more than one request to the same RequestBin, additional requests are added to the top of the page, one after the other.

Debugging Authentication problems using RequestBin

Here are some screenshots of parse_user_agent requests sent through RequestBin with different sorts of authentication problems.

Missing X-API-KEY
This screenshot shows a scenario where the X-API-KEY wasn't sent to the server. Note that you can't see it anywhere in the list of headers.
Screenshot of RequestBin's readout
This generates a missing_api_authentication message code when it is sent to our server.

If you are getting missing_api_authentication errors from the API; send a request to your RequestBin and if it is similar to this one - missing a X-API-KEY header - then something is definitely wrong with your request. Confirm that nothing is stripping out that header before it reaches us (switch to the https protocol to help prevent this), make sure your code is actually setting the header on your request, and make sure that you haven't misspelled the header name (remember, capitalisation of the header name doesn't matter).

Incorrect X-API-KEY
This screenshot shows a scenario where the X-API-KEY was sent to the server but is wrong. It appears in the list of headers but it's the QWERTYIOPSDFJLKJ clearly an incorrect key (copied and pasted from an example at the start of this guide!)
Screenshot of RequestBin's readout
This generates a api_authentication_invalid message code when it is sent to our server.

If you are getting api_authentication_invalid errors from the API; send a request to your RequestBin and inspect the result. Does your X-API-KEY header have the wrong key in it by mistake? Compare it with your key in the Accounts System. Have you created a new API key but are still sending the old one by mistake? Is the key being truncated somehow?

In both requests, you can also see the "RAW BODY" of the HTTP POST request at the bottom; it contains the valid JSON that our test script generated and sent to the server.

Debugging JSON problems using RequestBin

When you send your requests to RequestBin, you will see the Raw HTTP POST Body displayed at the bottom of the read-out in green.

Invalid JSON
This screenshot of a RequestBin shows a scenario where invalid JSON was sent.

Screenshot of RequestBin's readout with invalid JSON

This generates a invalid_json message code when it is sent to our server. You can notice the missing colon between the user_agent key and the user agent string.

If the problem with your JSON is not immediately apparent to you, you can copy and paste the Raw HTTP Body into a JSON Validator tool, which will validate and format it to be readable.

Screenshot of a JSON Validator showing an error message

If your JSON has a syntax error, the validator will indicate where it thinks the problem is. This example is telling you that it expects a colon, not a string.

If you're still stuck, you are always welcome to contact us and we'll see if we can spot the problem for you.

Conclusion

Introduction

This is the end of the Integration Guide. We hope you've found it useful.

Hopefully by this point, your system is hooked up to the API and working without any problems.

If you're having any issues, don't hesitate to contact us to get further help. We're always willing to give you whatever we can to get you going.

Feedback

We are very concerned with providing a high quality product and excellent documentation. If there's anything you think is wrong or missing from the documentation, or from the API itself, then please let us know about it. We're always looking for feedback on what we're doing. Good or bad - let us know.

Testimonials

We love it when our customers love our API, and if you'd like to share how the API has made your job easier, or how easy it was to get connected then we'd love to feature you in our testimonials section.

Even if you just want your logo to be included in the "This API is used by..." section, let us know!

References

API Specification

We use Swagger UI to provide an interactive API Specification.

Sample Code

We provide sample code for a number of popular programming languages, to give you examples on how to get started.

Support

In addition to the sample code and this Integration Guide, we have a support section which can give you further help.

Accounts System

Any time you need to discover or change something about your API account with us, head to our Accounts System: https://accounts.whatismybrowser.com/

There you can:

  • Change your billing details
  • Upgrade/Downgrade your API plan
  • Get and change your API key
  • Monitor your monthly API usage
  • Contact us with questions or suggestions

Back to the main API page