Getting started with the API

Note: We are not currently issuing new keys for the API is a well known page testing tool offered by dotMobi. When you supply a page URL to, it evaluates how well the page is likely to display on mobile devices by testing against the Mobile Web Best Practices, and dotMobi compliance rules.

The page checker also has a simple web service API. The API allows you to run mobile-readiness tests on your webpages without having to use the standard web interface. Upon request for a page test, the API will return its results as an XML document. The API thus facilitates programmatic use of the service. The possibilities are endless…!

Before you start

Before you get started with the API, you need to get an API key (it’s free!). Send us an email at Note that the API is still in beta, and that access to the API is limited by a quota system – i.e. your key is good for only so many requests per minute, per hour, per day, per month, so it is important to throttle your requests. This is easily done by adding a suitable delay to your code between requests.

Using the API

The URL at which the API can be accessed is:
To use the API, an HTTP GET request should be made to this URL, with query parameters as outlined in the next section.

An API key, provided by dotMobi, must be provided in the request. This key will be used by to identify who is making an API request. It also facilitates the tracking of the number of API requests over a specified period of time. Should requests be made too frequently, then an HTTP 403 (Forbidden) response code will be sent to the client. The client should not make another request until a suitable time has elapsed.
Example usage:


The following parameters can be sent with requests to the web API:

  • key (required): Your API key
  • url (optional): The URL of the page to be tested. If you omit this parameter, then you should instead supply the markup parameter
  • ua (optional): The user agent string that will send when it makes its request for a page. If this parameter is not supplied, then the default UA string will be used
  • accept (optional): The accept header that will send when it makes its request for a page. If this parameter is not supplied, then the default Accept header will be used
  • acceptCharset (optional): The AcceptCharset header that will send when it makes its request for a page. If this parameter is not supplied then the default AcceptCharset header will be used
  • markup (optional): Markup that you would like to test. See below.

Arbitrary headers

It is also possible to have send arbitrary headers, specified by you, along with its page requests. To do this, simply prefix the name of the header to send with the string ‘hdr_’ and append the header name and value pair to the API request. For example to send a header called ‘foo’ with a value of ‘bar’ you would request the following URL:

Posting markup directly

The API also supports direct posting of markup for testing. This requires that you submit an HTTP POST request, with the markup to be tested sent in the markup parameter. This is intended to facilitate page testing during the development cycle or other situations where the page is not live on a publicly accessible URL.

Note that if you test markup by posting directly to not all of the tests can be performed. This is because some of the tests depend on factors external to the markup. For instance, some of the tests depend on HTTP headers sent with a page, while others require access to resources referenced within the markup, and so on. Because does not perform all the tests when markup is posted directly, a standard score between 1 and 5 is NOT assigned to the results. Instead, a percentage is given which takes account of the tests which were actually performed and passed.

403 is not a bug!

As mentioned earlier, if you make too many requests to the API (currently set at 6 per minute), or if your key is not valid, you will receive an HTTP 403 forbidden response. To the uninitiated, this might look like a bug, but it isn’t! If you receive a 403 response, you should wait a suitable amount of time, and then make your API request again. If you always get this response, you should check that you have a valid key.

Code Samples

We now give some basic code examples to demonstrate how the API can be used programmatically. Code samples are given in Java and PHP. Sample XML output and the XML schema are also available for download below.


In this example we make a request for a page test, and extract the overallScore element from the XML results


This requests a page test, and parses the score from the XML results:

Download the full code listings below.

Exclusive tips, how-tos, news and comment

Receive monthly updates on the world of mobile dev.

Other Products

Market leading device intelligence for the web, app and MNO ecosystems
DeviceAtlas - Device Intelligence

Real-time identification of fraudulent and misrepresented traffic
DeviceAssure - Device Verification

A free tool for developers, designers and marketers to test website performance
mobiReady - Evaluate your websites’ mobile readiness

© 2024 DeviceAtlas Limited. All rights reserved.

This is a website of DeviceAtlas Limited, a private company limited by shares, incorporated and registered in the Republic of Ireland with registered number 398040 and registered office at 6th Floor, 2 Grand Canal Square, Dublin 2, Ireland