Insights and expereinces into making of APIs for a fleet management SaaS platform. Introduces and describes the functionality of the WEBFLEET platform and how this is made generally available through APIs. Focuses on the aspects of API making and API mangement especially in a B2B environment and the fleet mangement industry.

1. APIs and Services for Fleet Management
The B2B Perspective

2. Connecting Vehicles Around the World
Commercial Fleets Installed Base GPS Traces Density Plot (Sept 2013)
30 May 2014 @ToralfRichter :: tomtom.com/telematics2

3. The WEBFLEET® Platform :: In a Nutshell
TomTom Telematics Platform (Facts & Figures Q1 2014)
customers
28,000>
hours driving
1.4 M>
10 M
liters fuel
>
60 M
km driving
>
425 M
positions
>
units online
350,000> composed of ~25 application
deployables
the SaaS platform team are
~20 developers
runs 2 physically separate data
centers, employing ~4
independent Internet uplinks, 2
independent power suppliers,
and various, backup diesels
and batteries
Service Mesh: linked to 15+
major mobile network carriers
for communication with
vehicles, integrated with
various TomTom Group and
external APIs
Technical Facts
30 May 2014 @ToralfRichter :: tomtom.com/telematics3

4. Productized APIs and Interfaces
Stretching the API Idea to Make Connected Vehicle Use Cases Possible
● the API projects the platform product
● mostly indirect monetization
● protocol flavors: pragmatic, query-
based ReSTish + SOAP 1.2 with MTOM
● public API for complete fleet platform
functionality
● resilient, carrier-grade
● free for developers
● mostly free to fleet customers
● projects the product + is the product
● indirect and direct monetization
● technical protocol: Bluetooth® SPP,
multiplexing over same channel
● in-vehicle black box interface for 3rd
party devices
● simple data sink / source
● free for developers
● requires fleet customer to sign-up
NOTE: Calling a Bluetooth® interface an API is what I mean with “stretch”.
BUT WHY: In the connected vehicle space we are an aftermarket vendor. The
combination of the vehicle side interface with the open web API really has created a lot
of potential for developers.
EXAMPLE: E.g. ready mix concrete viscosity monitoring (theft detection).
WEBFLEET.connect LINK.connect
Open Developer Eco-System :: Build any Operational Fleet Solution you Want
30 May 2014 @ToralfRichter :: tomtom.com/telematics4

5. APIs as Tools and for Discovery
Data Vortices for Business Development, Back-Office, and Platform Integration
Scouting New Markets (UBI.connect, OBD.connect)
• “Unified Fleet API”: an orchestration layer on the WEBFLEET.connect product creates
the dedicated UBI.connect variety (API key based configuration)
• OBD.connect is a smart phone SDK to connect a OBD device to WEBFLEET
Experimental (Platform Connectors, Mash-Ups, …)
• e.g. outbound API for event based data synchronization to other platforms
• closed developer / user group: API contract defined and circulated
• e.g. TomTom myDrive Mash-Up using JavaScript SDK for UBI.connect and TomTom
LBS Platform
Back-Office Integration (CRM.connect)
• connect CRM and back-office systems of large partners (RMRs) to WEBFLEET®
subscription and contract management
• SOAP seems to hit the nerve for this specific clientele
• also used in consolidation of acquisitions (e.g. Coordina)
30 May 2014 @ToralfRichter :: tomtom.com/telematics5

6. Before Take-Off :: API Management
Checklist for a Safe Journey
“if it is released to GA,
it is bound to stay”
patience and a lot of
outbound communication
customers and partners
ask for continuity
Life Cycle Management
give some control of
behavior to developers
free / reduced price try-
out solution
accept who they are -
this is why we kept SOAP
Developer Appreciation
we tried both (add
versions, stay compatible)
overhead + cost of many
versions
“compatible evolution”
is the better strategy
Versioning / Compatibility
transform certain
“morphology aspects”
generalize as much as
possible and specialize
as little as necessary
Helps reuse
Orchestration Layer
stated fair use policy
rate shaping and quota
system
sign terms & conditions
app behavior, statistics
Platform Protection
SSL (only) is a must
IP white / black-listing
time control on
credentials
credentials + API Key
Authentication + Security
30 May 2014 @ToralfRichter :: tomtom.com/telematics6

7. Good Hope :: API Testing
B2B is Long-term. Navigating the Seas of Backward Compatibility
Why: In enterprise / B2B APIs the backward compatibility aspect is really
painstakingly important.
Business continuity of customers and software investments made by developers and
customers depend on it. The expectation is “carrier-grade” or “tap-water” availability.
How: Full stack, close to production, multi stage automated integration
testing. 1600 scenarios / test cases, nightly run 1:20 h – 1:50 h
Two test categories: Do, then compare to expectations, and do, then compare to same
operation in another version or protocol flavor.
As we want to make sure that all compatibility guarantees are kept there is a strong
focus on comparing to previous GA / production version. As we say the SOAP and ReST
API flavors are functionally identical, we check this too.
Integration test scenarios are sometimes coarse, so we started to close the gaps with
unit tests.
Why the focus on integration testing and on comparisons?
History: In the beginnings “specification“ was created by actual implementation.
Platform complexity: WEBFLEET® platform consist of many components that cooperate
and can have influence on data and functionality as available in the API.
Future: It helps us to move the APIs closer towards Continuous Delivery
30 May 2014 @ToralfRichter :: tomtom.com/telematics7

8. Heavy Duty :: Four Nines and Rising
How it pays (AlertSite Benchmark comparison US25)
Availability: Rank 2
• 99.99% across all
APIs and services
Roundtrip: Rank 2
• 1.1710 sec across all
APIs and services and
all locations and
carriers
AlertSite Monitoring
Locations
• Dallas (XO, Savvis)
• Munich (Lambdanet)
• Amsterdam (AMS-IX,
BNIX, DE-CIX)
• Boston (Cogent,
AboveNet, Level3)
• New York (Cable &
Wireless, Global
Crossing, Peer1)
• Frankfurt (Sprint,
Lambdanet, Interoute,
DE-CIX)
• London (AboveNet,
Level3, Global Crossing,
Peer1)
30 May 2014 @ToralfRichter :: tomtom.com/telematics8

9. In Retrospect :: Learnings and Experiences
Good-Humored Hints for API Makers
“Generalize till it Hurts, Specialize till it Works”.
Accept API styles that are not pure ReST. Pragmatic, query-based and even
SOAP are the better choice for certain cases.
Try to be wise about your life-cycle choices. Make a careful picks regarding
“Versioning” vs. “Compatible Evolution”. Think thoroughly before releasing
anything to GA. You will have to support it.
API Engineerîng
Accept “Emergent Strategy”. Up-front big design has proven many times it
can fail too.
More than the fair share of Novelty Pains hit you if your product or service is
relatively new and requires explanation about its general nature.
Be aware of the liability situation when sharing the same customer with your
partners and developers.
API Strategy and Eco-System
30 May 2014 @ToralfRichter :: tomtom.com/telematics10

10. Any questions?
TomTom Telematics :: tomtom.com/telematics
Toralf Richter :: @ToralfRichter