background image

DeviceAtlas API 1.4

daniel.hunt's picture
Posted by daniel.hunt - 31 Aug 2010
Twitter share icon Facebook share icon Google Plus share icon

This week was an important one for DeviceAtlas - we finally launched the new 1.4 version of our API!

Why 1.4?

The mobile web is constantly evolving, and with it, device detection needs to evolve too. With significant evolution in device capabilities, and large structural developments in certain device headers, the new DeviceAtlas API provides a highly flexible platform to cater for this growth, both now and well into the future.

DeviceAtlas' inherent intelligence, built directly into its device data files (rather than in the APIs), allows us to minimise the memory and computational footprint on your servers, and allows us to avoid requiring regular API upgrades whenever possible. This unique architecture is a key factor in DeviceAtlas' high performance levels, which is essential to many organisations.

With these two points in mind, we have developed a method to further improve upon DeviceAtlas' superior device detection!

What changes do I have to make to my code?


Let me repeat that again: NONE!

The 1.4 API was designed to be a drop in replacement for our existing 1.3 and 1.3.1 API users.
All you need to do is replace your existing 1.x API with the new 1.4 one (a single file replacement in most cases), deploy a new, updated JSON file and you should start seeing the benefits as soon as a new UA featuring this structure comes your way, if they haven't started hitting your servers already.

And if I don't upgrade?

Upgrading is completely optional. Our data files are designed to allow us to make incremental improvements such as this when required, without affecting backward compatibility at all. Your existing API will continue to function in exactly the same way, regardless of whether or not you have an old or a new JSON file.

1.4's major benefit is that its detection of Android, WebOs and WindowsMobile 7 is greatly improved. If you don't upgrade, you can't take advantage of this new feature.


1.4 introduces a minor reduction in speed, depending on your API and environment. That said, however, the beauty of our method is that any decrease in performance will only happen if & only if absolutely required. Our API will not function any differently unless the device headers passed to it match a particular structure or pattern!

The following table details the relative performance of our APIs (new -vs- old), for:

  1. Sample of 100k random UserAgents
  2. CPU: Dual Core Xeon 2.33Ghz
  3. RAM: 1.7 Gigs
  4. O/S: Ubuntu Linux

APIOld (recognitions/sec)New (recognitions/sec)% Diff

What about the beta APIs (2.x)?

The beta APIs, which were provided on the DeviceAtlas site, are being superseded by this release. The beta release proved not to have the flexibility to support the evolving conditions in the market, so we regret this version (2.x) will no longer be maintained.

Posted by daniel.hunt - 31 Aug 2010

daniel.hunt's picture

dotMobi hotshot & diver

Posted by James Pearce 5 years ago

But what does it do? ;-)

Posted by mbarr 5 years ago

Isn't having the IMEI a good thing? According to a previous post:

The first half of the IMEI number is the Type Allocation Code (TAC), which allows you to correctly identify the make and model of the phone. Why would you want to filter that information out?

Posted by daniel.hunt 5 years ago

That's a very good question actually...
TAC detection within DeviceAtlas isn't for use via our standard UserAgent detection method. TAC would normally be used behind the scenes on an operator level, where there may not be any web based activity at all.

As for the IMEI in a UA string being bad - that's purely my own opinion and was used in my example just to demonstrate the point. I have very strong reservations about my online activity being tracked in such an insecure manner - and one that cannot be filtered out via any options I set either :)

Daniel Hunt

Posted by voets 5 years ago

Will you be upgrading the Ruby API to 1.4 as well?

Posted by daniel.hunt 5 years ago

We will indeed - in fact, we have an update for Ruby in the pipes as we speak!
It shouldn't be too much longer, but I'll let you know as soon as it's ready.


Daniel Hunt