Developing the API Mindset

Preparing Your Business for Private,

Partner, and Public APIs

Nordic APIs
© 2015 Nordic APIs AB
Contents

Forward: Developing the API Mindset . . . . . . . . . ii

How to use this E-book . . . . . . . . . . . . . . . . . . . vi

Definitions – An API by any Other Name . . . . . . . 1

Introduction: Choosing Between Private, Partner

and Public APIs . . . . . . . . . . . . . . . . . . . . . 4

1.1 Overview: Why Start with Private APIs . . . . . . 1

1.2 Business Benefits of Private APIs . . . . . . . . . . 9

1.3 Private API Challenges: When a Private API is

Not Private . . . . . . . . . . . . . . . . . . . . . . . . 15

1.4 Case Study: Bisnode . . . . . . . . . . . . . . . . . . . 18

1.5 Reflections . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1 Overview: Building a Successful Partner API

Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2 Business Benefits of Partner APIs . . . . . . . . . . 31

2.3 Partner API Challenges: User Authentication to

Manage External Access to Data . . . . . . . . . . 37
CONTENTS

2.4 Case Study: LEGO . . . . . . . . . . . . . . . . . . . . 40

2.5 Reflections . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.1 Overview: Building a Platform and Ecosystem

with Public APIs . . . . . . . . . . . . . . . . . . . . . 46

3.2 Business Benefits of Public APIs . . . . . . . . . . . 53

3.3 Public API Challenges . . . . . . . . . . . . . . . . . . 59

3.4 Case Study: Podio . . . . . . . . . . . . . . . . . . . . 61

3.5 Reflections . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.1 Conclusion: The Roadmap from Private to Public

APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Endnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
CONTENTS i

Supported by Curity

Nordic APIs was founded by Curity CEO Travis Spencer and

has continued to be supported by the company. Curity helps
Nordic APIs organize two strategic annual events, the Austin
API Summit in Texas and the Platform Summit in Stockholm.
Curity is a leading provider of API-driven identity manage-
ment that simplifies complexity and secures digital services
for large global enterprises. The Curity Identity Server is
highly scalable, and handles the complexities of the leading
identity standards, making them easier to use, customize, and
deploy.
Through proven experience, IAM and API expertise, Curity
builds innovative solutions that provide secure authentication
across multiple digital services. Curity is trusted by large
organizations in many highly regulated industries, including
financial services, healthcare, telecom, retail, gaming, energy,
and government services across many countries.
Check out Curity’s library of learning resources on a variety
of topics, like API Security, OAuth, and Financial-grade APIs.
Follow us on Twitter and LinkedIn, and find out more on
curity.io.
Forward: Developing
the API Mindset
Open, semi-open, or closed? The degree of an API’s openness
was the question we had on our minds at the beginning
of 2014. We had been running into many people that were
dismissing APIs because they weren’t interested in or able to
launch public APIs. People were coming to our events, but
leaving disappointed because they weren’t able to open up
their services. This recurring phenomenon showed us that
there was an association in many peoples’ minds between
APIs and unfettered data access. We wanted to break this
incorrect stereotype that an API is always a public one.
We started this with a series of blog posts that we published
on our site. It was great to see how engaged people were
with this content. We connected with more and more people
online, showing that APIs can also be very useful for internal
purposes and within a partner network.
This was a good start, but we wanted to really drive this
point home and move the industry beyond this incorrect
mindset. To this end, we set off on a tour that took us to
Sweden, Denmark, Finland and Norway. In four days, we
met a couple hundred people who were implementing APIs in
these four cities. We were joined by regional and international
API thought leaders that reinforced the notion that APIs
are sometimes public but often private or semi-open. Since
this Nordic tour, we have held various other events and are

ii
Forward: Developing the API Mindset iii

committed to continually publish content that plays a part in

the ongoing development of the API scene. This publication
is an example of this determination.
Irrespective of how open or not open your API may end up,
this e-book is intended to help you develop a successful API
strategies. To do this, we show very clearly in this book that
there are three key API adoption patterns:

• Private APIs, AKA internal or enterprise APIs;

• Partner APIs that facilitate integration between a busi-
ness and their partners; and
• Public or open APIs.

Launching a successful API starts with the right mindset.

Should you develop your API for internal use, for partners,
for the general public, or a mix of these? Should you plan
to be closed at first, but then open up over time? What are
the consequences of this strategy? What aspects of your API
program should you prioritize at what points? After reading
this e-book, you will be able to answer these questions and
many others. With the correct outlook on how open your API
should be, you will be able to execute your API strategy with
confidence.
As you read this book (and afterwards), check out the Nordic
APIs YouTube channel for a deeper dive into the fascinating
presentations that were shared on our 2014 tour. Also, surf
over to our site and make plans to attend an upcoming event.
Signup to our newsletter to be notified of new events, e-books,
blog posts, and other info.
Thanks again, to our sponsors, presenters, participants, and
the online blogosphere for helping build a dynamic, forward-
Forward: Developing the API Mindset iv

thinking business community. I’m very glad to be apart of it,

and happy that Nordic APIs can play a part in the API scene.
Travis Spencer, Nordic APIs, Co-founder
Forward: Developing the API Mindset v
How to use this E-book

Our Goal
Application Programming Interfaces (APIs) are at the centre
of a digital transformation that is enabling businesses to do
more with less, to reach new markets, and to speed up product
and service development time. (See a complete definition of
APIs in the introduction.)
This e-book aims to help maximise the Return on Investment
(ROI) you are able to generate through the use of APIs.
We will explain the potential entry points for businesses
embarking on an API strategy, help you prepare a strategic
API vision and roadmap, and identify best practices and key

vi
How to use this E-book vii

resources that have been designed to assist you while building

your successful API portfolio.

Prerequisites
No prior knowledge is assumed in this e-book; it is aimed at
three key audiences:

• Business Developers and Managers who are starting

their API journey. This applies to those who have man-
aged an API pilot project and now want to incorporate
an API-driven approach into their organisational busi-
ness plan.
• Developers working within a business, who need a
resource guide for best practices. This includes those
responsible for ensuring that the API implementation is
aligned with an overall business approach.
• Enterprise architects who lead technological integra-
tion efforts. These are the individuals who document
how processes and technology can be leveraged to im-
prove business workflows and multiply the impact of
the business value chain.

Structure of this E-book

The following is an introductory section on the types or
the category of APIs that can be implemented. Subsequent
sections focus on each of these API types in detail, and follow
this general outline:

• A summary overview of the particular type of API

How to use this E-book viii

• The benefits of the API type

• Challenges and security issues to consider when imple-
menting this type of API
• A case study for each API type showing how businesses
currently implement it
• A set of reflective questions that prompt you into con-
sidering ways to implement the API type, and help you
use all this new information in a practical way
• Further resources and community outlets.

A final section discusses some of the roadmap and imple-

mentation issues facing businesses as they increase the use
of APIs in their enterprise. It also assists any businesses that
have started with closed APIs – accessible to a select group of
either internal stakeholders or to key partners – and explains
how to manage the process of opening these APIs to a wider
audience.

Inviting your Feedback

This is our second Nordic APIs e-book, and we have future
plans to support businesses with a range of other online and
print resources. To help us improve this and future publica-
tions, we invite you to share your feedback and thoughts.
Please tweet your comments about this e-book using the
hashtag #nordicapis. You can also post on our Facebook, or
email us at [email protected].
Definitions – An API by
any Other Name
API stands for ‘Application Programming Interface’. Tech-
nically, an API describes how to connect a dataset or business
process with some sort of consumer application or another
business process. Although you may not always recognize a
functioning API, you are probably familiar with a lot of the
big names that use APIs all the time. For example, whenever
you use your Facebook account to join another site, your
login request is being routed via an API. Whenever you use
the Share functions of an application on your mobile device,
those apps are using APIs to connect you to Evernote, Twitter,
Instagram, etc.
In addition, when you are accessing a location data, or per-
forming a state-abbreviation or postcode lookup in cloud
computer software, the function is often accomplished by
the cloud service calling an API. Frequently, APIs are the
connectors that are doing the heavy work of moving data and
performing specialized capabilities. We may not be aware of
this, because they are performing behind the scenes.
The sidebar, API Examples briefly illustrate other possible
functions an API can perform.

API Examples

1
Definitions – An API by any Other Name 2

One common example is a mapping API. When you

search for an address, an API helps interact with a map
database to identify the latitude and longitude, and other
related data, for that address. The API also makes it pos-
sible for a mapping interface to then display the address
on the map, and any additional information such as the
directions to that destination.
An API could also do things such as route machine data
to a program that will automate the analysis of that input
and send certain messages depending on the results. In
this scenario, the API ensures that the data is in a format
that can be understood clearly by a computer program
(i.e. it is “machine readable”). APIs help you monitor
data automatically, and share it only if something special
happens.
An API can assist you in recognising when someone has
placed an order on a website. It may then monitor the
order data to see if information needs to be forwarded to
someone responsible for same-day shipping, or whether
it should be sent to the normal shipping delivery queue.
Finally, imagine an API that can make it easier for a
business to pull relevant data out of a database and add
it to a useful report. The API provides a common format
that allows different applications to speak to one another.
You can also use an API with reporting software that must
display the extracted data in a usable format.
As you can infer from the many examples of APIs, these
services are much more than just a description of how
to access a database or how to help a machine read the
data. > APIs enable a business to become a platform.
APIs help you break down your business products and
services into composable functions you can share with
Definitions – An API by any Other Name 3

other businesses for direct insertion into their processes.

APIs provide a way for businesses to leverage new
markets. APIs allow partners and third-party developers
to access a business’ database assets, or create a seamless
workflow that accesses a business’ services.
For example, by opening up a business’ product cat-
alogue via an API, online retailers could include that
API provider’s products in their marketplace. This would
allow such a business to reach new customers in new
markets. A further example might be a business that
provides printing services. By exposing this core service
as an API, a third-party app developer could offer a
printing service directly from their mobile apps, helping
the printer reach new audiences. In this case, the app
developer doesn’t provide the printing service; they just
route the request via an API through their app to the
printing business, which charges and manages the service
request.
**An API is also a legal contract. **API documentation
includes a ‘terms of service’ agreement. This explains
how data can be used, and any costs associated with the
requests the consumer makes via the API. In this manner,
a business can stipulate how their data or services can be
used by commercial and third-party developers. It also
establishes a pricing mechanism for use of the data or
function exposed by the API.
In all of these examples, the company providing the
API must decide how open they wish their API to be.
Generally speaking, there are three degrees of openness
that a business may adopt.
Introduction: Choosing
Between Private,
Partner and Public APIs

APIs enable businesses to funnel data and services across their

organisation and to their wider network of suppliers, partners
and end customers.
Releasing a Public API can also have a long-term effect
on customer loyalty. Customers who use a business’ API
are likely to spend more and remain a customer for longer.
This happens because they are embedding the API provider’s
services and products into some part of their own business
value chain.
Understanding and identifying the different benefits and
limitations of Private, Partner and Public APIs is a conver-
sation currently being held amongst industry stakeholders
all around the world. It is a conversation being picked up
by existing businesses outside of the internet and Cloud-
based startup circles. The discussion is widening because

4
Introduction: Choosing Between Private, Partner and Public APIs 5

more organisations are seeing that a view of APIs through

a Private/Partner/Public lens can provide a more concrete
understanding of what businesses really need to know when
embarking on an API strategy. To see how this vantage
point can be helpful, let’s examine these three degrees of API
openness.

Private API Models

Two types of Private APIs can be utilised within a business.
The first type are those that are set up internally to link two
datasets or processes together. These are paired with business
logic in a very tight manner. This type of Private APIs are
often set in place by a top-down management process, and
their use is enforced behind the scenes by an IT department.
This type of Private API may also be used to expose a business’
data to its own mobile applications. In this case, the Private
API makes it possible for a business to access its data through
a mobile interface, such as an iPhone app. The API lets a
business get out from behind the desktop (or laptop) and
provide access to the data from any remote device.
The second type of Private APIs are those akin to Web
services, provided as a part of a Service-Oriented Architecture
(SOA). This kind of Private API provides an integration com-
ponent that is made available to anyone within the business.
They encouraged and facilitate reuse. This can often be a
bottom-up or horizontally-instituted API strategy. An API of
this type is created to encourage other departments to share
data or processes, and to facilitate team collaboration across
the business. This forms a sort of private library of APIs.
These can include self-paced resources that inform internal
Introduction: Choosing Between Private, Partner and Public APIs 6

developers across an enterprise on how they can use an API

to integrate and consume data source or business service.
Private APIs of either sort are often the preferred starting
point for many businesses. For businesses seeking to extend
their existing service-oriented solutions, the ability to auto-
mate internal data usage, and reduce duplicated processing
of information across departments, is a natural starting point.
Private APIs also have the advantage of not overexposing
the business as it learns about APIs. A strategy that begins
with the launch of Private APIs allows a business to see
where their APIs are inadequate, or where difficulties occur
when using their APIs themselves. This is preferred because
any failures may occur will only affect the API provider
itself. Conversely, businesses that initially expose APIs to
partners and customers may lose their trust if the partners or
customers are inconvenienced by an improperly functioning
API.
In and of themselves, Private APIs create multiple benefits
for businesses, without the need to open up the API any
further. Private APIs are at the core of a business’ digital
transformation, and generate efficiencies and productivity
improvements across a business’ operations.
While Private APIs allow a business to learn through expe-
rience, it is no short cut. Private APIs require resourcing in
order to create the productivity gains that are promised in
an API-enabled environment. This may mean providing a
suite of user services, for example, documentation, Software
Development Kits (SDKs), training videos, and detailed error
messaging. These should assist internal developers to success-
fully integrate an API into their business functions.
Introduction: Choosing Between Private, Partner and Public APIs 7

Partner API Approaches

To leverage business relationships in a distributed environ-
ment, companies are also beginning to turn to partner-based
APIs as a way of collaborating effectively. This allows part-
ners to utilize the customer relationships of one business
with another. For instance, the Swedish Digital PR agency,
Deportivo, uses the APIs exposed by various Cloud providers
to facilitate partnership communication. Deportivo’s Art Di-
rector, Arvid Dyfverman, said the agency uses APIs from
project management tools like Trello and Basecamp to involve
partners in their creative design projects.
Danish business network platform, Tradeshift, has created a
Public API to help customers more easily integrate business
networking services into their legacy systems. To help end
customers achieve this, Tradeshift has also created a suite
of Partner APIs that are designed with the end customer in
mind. As a result, the Partner APIs enables broader adoption
of the company’s Public APIs. This type of multifaceted API
strategy is indicative of one developed by an organisation that
has progressed beyond one of API provider to that of an API
platform.

Public API Releases

Public, or open APIs, can rapidly grow a business’ market
share and customer base. Swedish online retailer Fyndiq, for
instance, found their sales volumes per month grew signifi-
cantly after making their product catalogue available via API.
Once they launched their API, their problem became keeping
Introduction: Choosing Between Private, Partner and Public APIs 8

up with sales, not getting sales, co-founder and CTO, Micael

Widell, told Nordic APIs readers.
Other companies are finding they can monetize their API
as a new commercial product or service, with developer-
customers willing to pay for access to the stream of data or
functionality opened up via an API.
Tom Burnell, from API management provider, Axway, shared
details of several Nordic businesses that are opening up their
data and capabilities via public-facing APIs. He points to
Essent, the Swedish energy company that uses APIs to help
customers optimize their energy usage. Nordic telecommuni-
cations company, 3G, is using APIs to allow customers to top
up their prepaid phones. This is creating a new direct revenue
channel for them in addition to their existing model that relied
on sales made solely through value-added resellers.
Meanwhile, some of the Nordics’ fastest-growing online busi-
nesses, such as Moves in Finland, Spotify in Sweden, and
Podio in Denmark, are making use of Public APIs as part of
their hyper-growth strategies.

The Origin of your API Journey

It is often said that businesses can expect very high impacts
from releasing Public APIs. In reality, however, it will most
likely take an extensive period of time to build recognition
and adoption of your API among third-party developers. This
is clear when you consider it likely that you must more or less
coax an ecosystem into existence.
While Private APIs make sense for automating data processes
and encouraging collaboration in larger businesses, it is Part-
Introduction: Choosing Between Private, Partner and Public APIs 9

ner APIs that have a high potential for quickly generating pos-
itive business impacts. Depending on the size of the enterprise,
it may be the best starting point for a business’ API strategy.
Beginning with a public-facing API is recommended with
caution. As mentioned before, there are a lot of opportunities
to learn from deploying an API internally or with partners
first. This is important as trust can be lost so quickly. The
detrimental effects of accidentally exposing a third-party’s
business data could immediately undo any adoption or recog-
nition you have gained for your API. Starting with Private
or Partner APIs will also help a business identify the normal
range of API consumption. This makes it easier to make
accurate capacity plans and set appropriate rate limits, so
resources are not overused by low-priority consumers. It also
helps to monetize high-end users as you pivot to a public API
release.
The following sections shares how Nordic businesses are im-
plementing business-wide API strategies and offers guidance
for businesses anywhere in the world who are seeking the
benefits of each of these three categories of API.

Additional Resources
• The rise of the API economy and consumer-
led ecosystems
1.1 Overview: Why
Start with Private APIs

“While each business and situation is different, we’ve seen

many organisations choose to launch a private or partner
API rather than a public one out of the gate,” says Ronnie
Mitra, Director of API Design at CA Technologies. Starting
with a Private API addresses the reluctance and concerns
some businesses have when starting their API journey. These
fears are lessened by Private APIs because they ensure that
an organisation can:

• Make mistakes and changes behind closed doors;

• Staff up on the resources needed to properly support a
public API offering after obtaining success with a private
one; and
• Realign the business to benefit fully from the effects of
an open API.

1
1.1 Overview: Why Start with Private APIs 2

Ronnie added that “many API owners have longer-term vi-

sions of opening up APIs to the public and use a closed API as
a springboard.” He says that this closed-first-open-eventually
strategy results in the infrastructure build-out required to
solve longer-term needs of the business. Ronnie also pointed
out that product owners often have an eye on the future, and
use this initial foray into APIs to incrementally expand to a
broader audience.
Even without a clear case for eventually opening up an
API, a Private API approach can add significant benefits to
a business. For example, any process that requires data to
be copied from one system or process to another can be
automated via an API. This has the advantage of reducing
human errors that may be introduced when moving data from
one place to another. Automation also improves productivity
by alleviating the need for duplicate tasks. Using Private APIs
for internal data transfer also reduces errors introduced when
multiple versions of a dataset are strewn across an organisa-
tion. Reliance on a Private API improves data integrity and
reduces clutter.
APIs can also be used to speed up process and authorisation
movements across a business. For example, businesses often
have accounting policies that require appropriate authorisa-
tion for anyone purchasing above a certain amount. Private
APIs can be used to trigger workflow approvals automatically,
reducing risks and workload in moving tasks along a business’
operational flow.
Private APIs are similarly used in new product and service
development. Private APIs can trigger automatically when
other departmental teams or stakeholders need to be involved.
This action can make a set of common resources available to
everyone involved in the production teams.
1.1 Overview: Why Start with Private APIs 3

Focus on User Experience

One goal of a Private API is to ensure that it is tightly con-
trolled and will restrict access only to internal users. Thinking
about Private APIs in this way can help lower the priority of
API usability. Private APIs often have a poor user experience.
This should not be the case. In a manner similar to the way
a company’s intranet is often much less user-friendly than
their public-facing website, Private APIs tend to neglect the
developer experience.

Research data from Nielsen Norman shows that companies

investing in intranet usability receive productivty increases
worth eight times the design costs required to achieve them.
Research indicates that this factor increases for larger compa-
nies. The same sort of productivity benefits can be hypothe-
sized about an investment in the design of usable Private APIs.
While not proven through similar research, the correlations
1.1 Overview: Why Start with Private APIs 4

are strong enough to suggest that new users can make the
most of the private APIs when focusing on the following
areas:

• API design,
• Documentation,
• Error handling,
• Testing,
• Inclusion of SDKs, and
• Internal knowledgebases.

A Common Approach to Private

APIs
When a use case identifies the advantage of a Private API, it
is important to consider other potential uses of the dataset,
or functional capability exposed by the potential API. This
ensures that APIs are not created for each individual use case.
If each one is unique to a given problem, the enterprise will
be encumbered by the initial APIs as it continues along its
API journey. This generalization of an API can also help avoid
dataset duplication and ensure consistent API design practices
are adhered to across APIs. This is important because in many
successful cases Private APIs are opened up to a wider user
base than originally expected. In the case of legacy APIs it is
especially important to follow this practice to avoid problems
and tying up developer resources.
Businesses often repeat the same problems when trying to
open up their datasets via APIs. Depending on which system
is used, the data can have different names, allow different
string length, or have different identifiers. Michael Widell
1.1 Overview: Why Start with Private APIs 5

from e-commerce vendor Fyndiq says this is one of the ben-

efits of starting with Private APIs: you can focus on making
sure the data you expose has consistent naming conventions
and other formatting rules. If you expose the data via an API,
you can manage the formatting and naming in one place – the
API – as you scale the usage to partners or the general public.

Identifying Internal API Use Cases

Anne-Sofie Nielsen from enterprise, data-scraping company,
Kapow Software, has seen how her business customers are
using internal APIs to create efficiencies and to encourage
staff to concentrate on more interesting, useful work. “If you
automate internal processes there are cost savings,” she says.
“Whenever you eliminate people having to manually update
or extract information from internal systems, it’s a pretty
easy calculation to see how many resources you free up. In
many cases, companies have more productive things their
employees could be doing, which ultimately enables them to
grow revenue,” Anne-Sofie further explains.
She has seen how some customers have used APIs to signif-
icantly reduce burdensome data transactions between inter-
nal and external systems. “Obviously there are cost savings
from reducing the customer support response times from, in
one customer’s case, ninety minutes to approximately four
minutes.” However, she adds, “but I am sure that will also
have a long-term effect on their customer’s perception of
the company, which will have effects on customer retention
numbers.”
Anne-Sofie shared with attendees of one of our events in
Copenhagen how her customers are using internal APIs that
1.1 Overview: Why Start with Private APIs 6

follow a basic principle: Use people to accomplish what a

computer cannot do as well. As she explained in the recorded
version of the presentation, “Let’s put humans to work where
we need human minds, and let’s automate the rest. This frees
up resources for higher-value tasks.” This could include:

• HR automating manual reporting processes

• HR extracting data on current salary levels in other com-
panies’ job ads to be able to make market-competitive
salary offerings to new candidates
• IT automating complex workflows around defect track-
ing
• Accounting automatically validating partner rates ver-
sus client rates, using humans when exceptions arise
rather than having to audit every invoice.

Robust Private APIs Become

Partner APIs
At Finnish software company PlanMill, the first twelve months
of using the API was a period of uncertainty. Marjukka
Niinioja, Senior Consultant and Manager at PlanMill, says
that staff were unsure how to sell the API features to partners
and customers. They were also initially unclear on how to
provide the best usability and ensure supportability with
regard to testing, API key registrations, documentation, and
other factors. They learned these things incrementally by
using the API themselves. This so-called practice of “eating
your own dog food” gave the PlanMill team a deep insight
into the potential and power while also helping them build
awareness of the drawbacks and challenges of using their API
1.1 Overview: Why Start with Private APIs 7

before it was integrated with partner systems. “I never want

to see dog food again,” Marjukka joked when presenting to our
Helsinki event audience about the steep learning curve. It was
worth it though, she added. Because of their initial internal
testing, their eventual public API was better designed. Later
testing and usage was not such hard going, and they were able
to “swap from dog food to donuts!”
To encourage internal stakeholders to integrate their systems
via the API, Marjukka repeated several mantras whenever
talking with her colleagues:

• Who has some great examples of using our API?

• Have you tested that with the API?
• Have you added that to the API documentation?
• You can do this quicker and cheaper using our API.

Getting Started with Private APIs

Private APIs may well be the best way for some enterprises
to commence their API strategy. Starting with internal APIs
can help identify the best integration pathways. In addition,
this approach lets you design a roll-out strategy that will en-
courage ownership and commitment from across all business
operations.
One of the best places to start is by asking staff to identify
those occasions when they have to cut and paste data from
one process to another. Seek to find datasets that are used
across an organisation, or by multiple staff members. Review
previous problems, and what new ones are arising from a lack
of version control of data. See if those problems could have
been solved by having a single dataset. When you determine
1.1 Overview: Why Start with Private APIs 8

the cause of the problems, you may discover another key

starting point for your Private API implementation plan.
You can also identify all workflows where a decision must
be made about the state of a process before the next step
is activated. In some of these cases, the discretion of an
authorised manager will be required to decide whether or not
to move the process forward. In many such cases, the only
decision being checked is assuring that the previous process
has met certain post conditions (e.g., adherence to company
spending limits). A Private API can automate many of the
processes that involve decisions based on a policy definition.
1.2 Business Benefits
of Private APIs
For many businesses, there can be a great reluctance to
opening data assets and business capabilities via APIs to
external partners or to third-party developers. One way to
start assessing the benefits of an API business strategy is to
begin using APIs internally. Private APIs can lead to faster
time to market (TTM) for new products and services. This in
turn can lead to the opening of new market channels. Private
APIs can help to ensure that any one organizational process
does not create bottlenecks in the business’ workflow.

9
1.2 Business Benefits of Private APIs 10

Private APIs Can Commence the

Journey
According to Mark O’Neill, VP of Innovation at Axway, an
international API management service provider, many busi-
nesses face a ‘push-pull’ demand for using APIs. Businesses
may be requested by partners and suppliers to connect via
API; they may also find a competitor has an API. In such
cases, they realise they, too, need and API, and are pulled
in that direction. Mark sees Private APIs as a good way for
businesses to remain stable as the market pulls them further
into the API playing field.
“A lot of businesses started by deploying SOA [Service Ori-
ented Architecture] inside their organisation and moved on to
using APIs beyond the firewall in the so-called omni-channel
world,” Mark said. “Often it goes that the first thing people do
is internal integrations, then they might have a partner that
wants to integrate which creates the requirements for an API
that works across the firewall and all the security that comes
with that.”

Private APIs Modernize

Organisations
As companies begin using Private APIs to manage internal
processes, they often discover the opportunity to restructure
and modernise their business to enable the “composable en-
terprise”. The key concept behind the composable enterprise
approach is this: by breaking down a business’ functionalities
and services into LEGO-like pieces, it is possible to create
1.2 Business Benefits of Private APIs 11

new links in the business value chain by composing services,

data and functionalities into new configurations. It also al-
lows businesses and enterprises to access a greater range of
resources by enabling many non-core business operations to
be moved to external providers and Cloud-based services.

Private APIs Improve

Collaboration and Internal
Communication
Internal – or Private APIs – can offer substantial benefits
in efficiency and productivity. A study by the McKinsey
Global Institute estimates that companies can achieve a 20
to 25 percent increase in productivity by improving internal
collaboration: a strategy that is only possible with the use of
APIs.
It is a benefit that Eva Sjökvist from the Absolut Company
sees in the global alcohol beverages enterprise. Eva told atten-
dees of our first annual event in Stockholm that Using an API
across their organisation has meant a greater shared aware-
ness of the company’s data models. It has also created greater
clarity by enabling consistent data to be used when analysing
the business’ operations. Internal business stakeholders had
more “confidence in the data models and structure creating
greater leverage for new ideas”, Eva went on to say.
1.2 Business Benefits of Private APIs 12

Private APIs Speed Up Time to

Market
As mentioned above, internal APIs can significantly speed
up TTM for new products and services. In part, this is an
extension of the benefit from improved internal collabora-
tion, as Joakim Skog from the Swedish business information
company Bisnode points out. He says that Bisnode works
“with APIs internally when we design new [business] services.
Everything we have internally from data sources and services
like that are on APIs.” (For more on Bisnode, see the case
study at the end of this chapter.) However, there are other
ways that using APIs speed up TTM. Joakim Rapp, Lead
Developer at Nordic online content provider Viaplay, says
that using private APIs brings more efficient allocation of
internal resources. This allows the company to create and
release new features to the market more quickly.
According to Joakim, “When you develop new features in
general, APIs make it possible to have a team working on
the user interface and another on the business logic layer,
for example. You don’t have to have all your developer team
working on everything and it creates a better flow.”

More Efficiently Manage the

Value Chain
Joakim from Viaplay also explains how the composable enter-
prise approach results in a more efficient business value chain.
One of these benefits becomes apparent when implementing
1.2 Business Benefits of Private APIs 13

new features: “When delivering new functionality, it is impor-

tant that it doesn’t impact existing services,” he advises. “We
want a robust architecture that makes it easier to develop one
component that works well and makes it easier to build and
integrate new components as we go.”
The value of this approach can also apply when managing
existing service delivery to customers. He gives the following
example of how two of Viaplay’s internal APIs are managed:

One API is used to check a customer’s current

subscription level, to see if their account is active,
and if they have the right subscription to access
specific content.
Another API makes it possible to re-commence
the subscriber’s content at the last known viewing
point.

If these two aspects are interlocked in just one value chain,

any slight error in determining what content was last viewed
could disable the customer’s whole account until the playback
error is resolved. So, while the ability to restart the viewer’s
content at the point where they left off enhances the customer
experience, it is not an essential feature. Through their use of
APIs, Viaplay ensures that if there is a problem, the customer’s
account remains active and they can still access content (even
if they have to restart it manually from where they left
off). This approach is much preferred over a situation where
the customer is unable to access their account because, “the
supply chain falls over due to a single, errant, intertwined
process.”
1.2 Business Benefits of Private APIs 14

Private APIs Provide Precise

Business Intelligence
Internal APIs allow businesses to better identify where there
are problems in their operations. A composable enterprise
that is assembled together from numerous private APIs, pro-
vides numerous points at which the company can monitor
the system for problems. Joakim from Viaplay explains: “One
other perk of decoupling business services via APIs is that
it gives a better view of what parts of our system might
slow down. It is easier to manage single components. We can
monitor response times, uptimes, and the load on the servers
and share the analytics that are important for the C-level of
the business.” In this way, private APIs help detect errors and
provide actionable intelligence to decision makers.
1.3 Private API
Challenges: When a
Private API is Not
Private
Businesses often start by creating a Private API that can
serve data to a mobile application. This could be an app that
replicates the business’ website, or offers specific services to
mobile users. It could also be an employees-only mobile app
that supports a Bring Your Own Device (BYOD) program
of the enterprise, in which case employees need access to
business data. Even Corporately Owned, Personally Enabled
(COPE) devices need such data access. In all these scenarios,
a Private API is being used to communicate between the user-
facing interface and a business’ back-end system. Even the
simplest apps often use some kind of API.
Without appropriate security provisions though, it can be
very easy to see what network traffic takes place between
such a mobile app and the server. This would allow third-
party developers to see how the app’s API works, even if it is
not documented. This means that a Private API for a mobile
application is actually a thinly-veiled Public API.

15
1.3 Private API Challenges: When a Private API is Not Private 16

How your Private API is Reverse

Engineered
There are several tools to intercept a private, undocumented
API. For example, the tool Charles Proxy can capture all the
traffic sent to and from your phone via this proxy, which runs
on your computer. By installing some certificates, this and
other tools like it can also intercept SSL-encrypted traffic and
show it as plain text. SSL is good, but in this case it actually
does nothing.
There are cases where developers have used these tool to
identify what traffic is being sent to and from an app. By
inspecting the resulting data, they are able to figure out how
to use the API as if it were a Public API, even if it is only
intended for internal use. In some cases, developers even share
their research on GitHub, more or less documenting a Public
API so other developers can also use your Private API.

Security Implications
The main lesson from this very real example is that security
through obfuscation is not a viable option if the data your
API exposes is of any worth. Just because you do not have a
public webpage for your API, or have not made any public
announcements that you even have an API, does not mean
that external parties can’t find it and learn how to use it.
Hiding APIs via obfuscation can be sidestepped in a few
minutes. Anyone can see how your API is designed, what API
credentials (e.g., API keys) you use, and what data is sent back
and forth.
1.3 Private API Challenges: When a Private API is Not Private 17

Do not despair. Even if others can see the traffic between their
phone and your server, it does not mean that unauthorised
users should be able to easily access your API. If your appli-
cation’s API gets documented and used by developers, you
have a great confirmation that there is a market for a public
API. Treat this as free market research. Try to see traffic
interception as an opportunity and not a threat.
The main lesson is to design your API as if it were public
even if you only plan to use it in your own mobile app.
Protecting the data comes down to your API security scheme.
If you are using API keys, HTTP Basic, or similar protocols,
all the credentials will be visible to intermediaries. Anyone
can snatch your API consumer’s keys to access your data, so
use a protocol, like OAuth 2, that authenticates not only the
app but also the end user.
1.4 Case Study: Bisnode

We’ve had web services and APIs as a part of our

offering for a very long time, but since Bisnode
used to be a group of 70 companies in 19 countries,
every company working with integration of our
data and services in our customers systems had
their own strategy and architecture.
Now as we are joining forces. This will converge
over time, but it needs to be managed and well
thought through to build a solid platform for future
growth. So, APIs and integration are increasingly
becoming more important as a way of creating
a standardized internal platform for accelerated
development of new products and services.

Joakim also told us that before the company is ready to

move towards Public, open APIs, it first needs to implement
efficiencies by using Private APIs internally.

Apart from being able to explain the concept of

APIs to C-levels, you also have to work on the
numbers, because although implementing APIs is

18
1.4 Case Study: Bisnode 19

a no-brainer and more or less a hygiene factor

from a development perspective, you still need the
business case to show green numbers. Some people
listen to the dreams of tomorrow, some on how
today’s work can become more effective, and some
only look at the numbers. You need to have the
story set for all of them.

Joakim believes that by focusing on the business case for using

Private APIs, the culture will be created for later acceptance
of open APIs as outward-facing commercial opportunities:

The first time I started talking internally about

open APIs back in 2010 I was quite heavily criti-
cized, and the lesson there was that I wasn’t ped-
agogical enough. There are many misconceptions
around APIs and when raising a topic like that in
a company where the core asset is refined informa-
tion, you need to first explain what APIs are before
you can put it in relation to your line of business.

Key Lessons
• Involve team members from each department in inte-
gration planning and building buy-in for implementing
APIs internally
• Prepare a one-pager and an elevator pitch explaining
APIs so that you are able to start the conversation at
whatever level of sophistication your internal stakehold-
ers may be – usually at the very beginning!
• Treat internal stakeholders as you would external cus-
tomer segments. Be prepared with the legal benefits of
1.4 Case Study: Bisnode 20

using APIs for the legal department, potential revenue

benefits for the sales staff, and bottom line business
benefits for the C-level.
• Research your business case: use studies like the Nielsen
Norman research to quantify potential productivity ben-
efits derived from using APIs.
1.5 Reflections
• What initial use case is motivating an exploration of
APIs? What processes that involve copying and moving
data from one system to another are performed most of-
ten? What data entry processes are prone to the greatest
amount of human error?
• What datasets are employed in this use case? What other
internal stakeholders use this dataset?
• Does the dataset have a data dictionary that includes
common naming conventions and rules for defining how
to maintain time and date, location, currency, etc? Are
these rules standard across the entire business or do
some parts of the company use the datasets differently?
• Who are the internal customers who will be consuming
the API, and who will be responsible for integrating it
into their departmental systems? Who will be receiving
the value from automating processes or accessing busi-
ness data via this API? How are you involving these
players in the API design project?
• What resources are available for your business’s in-
tranet? Can some of that be allocated to the * Have
you identified metrics to assess the effectiveness of the
private API, such as time saved over current manual pro-
cesses, reduction in accidents or errors from integrating
data to avoid re-entering it from one system to another,
etc?
• Do you have a process to track API calls? What about
error messages? Is there an existing alerting and moni-

21
1.5 Reflections 22

toring system in use that you should leverage with your

new API (e.g., one that is being used with your website).
• Are there Cloud-based software tools that you are cur-
rently using in your business? Do you use their APIs
to integrate the software with your legacy systems and
databases? Do you use their tools to make it easier to
use their software across business departments? What
feedback can you get from business stakeholders who
are using these APIs in their work?

MoreResources
• Adapting to an API Enabled World (Panel
Debate)
• The Business Impact of Private, Partner and
Public APIs
• Twitter accounts to follow:
– Ronnie Mitra
– Nordic APIs
– Tweet feed of all past, present and
future Nordic APIs presenters
• Nordic APIs newsletter
2.1 Overview: Building
a Successful Partner
API Strategy

Using specifically-designed APIs to work more collabora-

tively with partners can build trust in business relationships
and enable 24-hour access to your business’ supply chain.
However, one-off Partner API strategies can also be costly
to manage. They can challenge existing relationships with
trusted suppliers and business contractors. The following
sections address some of these issues.

Where to Start with Partner APIs

When starting with Partner APIs, Mark O’Neill, VP of In-
novation and Product at API management provider Axway,

23
2.1 Overview: Building a Successful Partner API Strategy 24

encourages businesses to start with the ‘low-hanging fruit’,

which is usually what partners are looking for anyway:

Often there are clear interfaces that make sense

with APIs: price catalogs, order status lookups and
shipment lookups, for example. B2B will require
ways to go in and look at these interfaces, so they
are good candidates to have available to partners
as an API.
Beyond these more straight-forward API use cases,
identifying Partner API opportunities often requires
case-by-case communication at the start. When the
first use case is identified, as with Internal APIs
discussed previously, it is important to look for a
similar use case with other partners. This can help
identify common datasets, and makes it easier to
scale a Partner API with additional partners at a
later stage.

With all types of Partner APIs, monitoring of API access is

essential for measuring the value and future potential of a
Partner API strategy.
2.1 Overview: Building a Successful Partner API Strategy 25

Building Partner APIs That Can

Scale

Swedish banking and insurance group Skandia is working

with partners who have not previously had an API to help
them integrate with the group’s IT systems. This has created
challenges for the financial institution as they have sought to
scale their partner strategy. Dennis Skantz, Solution Architect
at Skandia Norden explains:
” Historically, we have not been able to bring on new partners
and integrate them easily with APIs. So, it makes it really
expensive to take on new partners, as in the end we have
ended up with a specific service for each partner.”
Dennis is confident that Partner APIs will be the answer. As a
2.1 Overview: Building a Successful Partner API Strategy 26

financial company, Skandia aims to keep its focus on its core

business, and is keen to build secure systems that will restrict
data access to selected partners only. For example, by using
an API rather than a one-off system, Skandia’s partners will
be better able to build customer-facing apps.
“Our APIs are primarily for partners. We don’t currently have
any plans to release an open or even semi-open API. We may
do so in the future though,” Dennis hints. This successive
opening of APIs is very normal.
To manage the way Skandia works with Partner APIs as it
grows, Dennis uses a term from the Swedish traffic authority.
“They have a ‘zero vision’ where their goal is to have zero
fatal accidents in traffic. So, they need to design roads such
that it is not possible to have a fatal accident. I like to think of
our work as having a zero vision: we should need to have zero
lines of code to integrate with a new partner. It is naive. You
will never reach that, but that’s the goal in our API design.”
According to Dennis, there is a clear-cut business motive for
striving towards scalable partnership APIs in future:
“Collaboration is not going away. Business success will de-
pend on who can collaborate with the most partners at the
least cost. We want to create a platform for Skandia where
we don’t just bet on one horse. We want a platform where it
doesn’t hurt us so much to work with multiple partners.”
Making Partner APIs work effectively, and being able to scale
the on-boarding process when bringing in new collaborators
is still a business process in its infancy.
In fact, many companies find it difficult to create scalable
API infrastructure. They find themselves taking relationship-
specific approaches with the APIs they provide to external
2.1 Overview: Building a Successful Partner API Strategy 27

partners. This challenge has by no means been solved, but

innovators like business network platform Tradeshift as well
as Skandia are at the international forefront of experimenting
with processes they hope will reveal new ways to conduct
partnership on-boarding.

Partner APIs Reflect Your

Business Relationships
Tradeshift sees that for many partners it all comes down
to the ability to communicate around API needs. “It’s a
people thing,” says Jeremy Glassenberg, Platform Architect
at Tradeshift. He adds:
“You need to be able to just hear what the partner’s particular
challenges are. You’ll talk with partners to understand their
needs and coordinate on the design of a compelling solution,
and from there, you will support them on a technical level
throughout development. What I found on any good enter-
prise platform team, is the ability to properly listen to partners.
Don’t just listen for the features they’re requesting, but rather
ask why they want that feature. You may hear a proposed
solution first, but it’s important to dive into their problem.
From there, you can give a different perspective that results
in a higher quality, and easier-to-build solution.”
Sumit Sharma, Director of API Solutions at B2B integration
and API management provider MuleSoft, echoes Jeremy’s
engineering advice.
“This notion of B2B integration is nothing new,” Sumit says.
The means of achieving connectedness has progressed, he
says, but “there has always been the objective that we need to
2.1 Overview: Building a Successful Partner API Strategy 28

collaborate. We have always been trying to securely transact

relationships with partners. What is different is that now
there are multiple B2B protocols spreading out and that
requires a much more thorough orchestration and integration
play.”
Sumit strongly suggests that a ‘whiteboarding approach’ is
needed when designing B2B APIs. Mapping out the process
flow, identifying data and other sources, and ensuring all
stakeholders are involved is important when designing Part-
ner APIs. He also urges API developers to use API service
descriptions as part of a best practice design, so that partners
are better aware of how to consume and integrate the API
into their systems.
As APIs become a key tool enabling businesses to communi-
cate and share information effectively across their boundaries,
API service descriptions will allow the humans managing
the interactions to better understand each other – and what
is possible via API capabilities. While not there yet, Sumit
sees a time when API service descriptions will be written in
plain language that can be composed by non-developers. This
will allow other than engineers to understand what data and
functionality an API is enabling.
2.1 Overview: Building a Successful Partner API Strategy 29

Using Metrics to Understand

Partner API Usage
Skandia, Tradeshift and Norwegian life insurance company
Storebrand all look to API metrics to help them understand
partner usage and to control access. This may involve setting
usage quotas, such as number of calls per hour, and setting up
throttling limits for excessive usage.
Jeremy at Tradeshift notes that setting quotas may not neces-
sarily lead to rate throttling. More supportive techniques are
available to improve the flow of data with business partners,
he explains:

Try to understand what your partners are doing.

They might be polling APIs out of necessity, and
would be more than happy to work with webhooks
or long-polling if you can provide it. That could
reduce performance hassles for you and for your
partners. That path can help you avoid having to
2.1 Overview: Building a Successful Partner API Strategy 30

set restrictions that limit the ability of connected

apps, and creating more challenges for partners.

Life insurance company Storebrand has a sophisticated mea-

surement system in place, according to Terje Borgen, Platform
and Integration Department Manager:

We have our own custom-made monitoring sys-

tem and a custom logging system as well. The
monitoring system monitors selected services, and
the logging system logs all traffic including errors,
payload, response time and more.

Mark O’Neill from Axway agrees on the need to measure

partnership usage of APIs. By tracking partnership API con-
sumption, it may be possible to see new product development
opportunities down the track. He states that: “For business
partner APIs, you can still set quotas. Then you can see trends
over time that can help you see the take-up of the partner
service. This can help enable ecosystem development and lets
you later introduce monetization strategies, which you can’t
do if you don’t have a quota in place.”
2.2 Business Benefits
of Partner APIs
Partner APIs are an ideal starting point for smaller businesses,
where the productivity benefits from using private APIs is less
urgent. For enterprises that have seen the benefits of using
private APIs, it may now make sense to start opening APIs to
external consumers in a controlled manner. Partner APIs are
a great place to start.
Partner APIs are an extension of good business relation-
ships. The types of benefits that can be expected from strong
relationships with suppliers, resellers, agents, and partners
can manifest more quickly when you use APIs that enable
communication and the sharing of resources.
APIs also generate benefits that are much harder to leverage
through other forms of relationships or shared work. Speed
and efficiency when communicating in highly regulated busi-
ness environments, and facilitating the availability of your
products and services to your partner’s customer base, are two
major benefits that are much more difficult to realise without
using APIs.

Partner APIs Build Trust with

Suppliers and Business Partners
Providing partners with access to key information via API
so that they can better manage their own supply chain is an

31
2.2 Business Benefits of Partner APIs 32

ideal starting point when creating a Partner API. This is why

experts like Mark O’Neill from API management provider
Axway recommend opening order tracking and product cata-
logs via Partner APIs. By opening up real-time information
from these two data sources, partners are better able to
manage their own workflow without having their systems
grind to a halt while they check for updated information.
Access to real time information is especially important in
a global business environment, where time differences may
mean a partner’s workflow is taken offline for a whole work-
ing day while they await information. Product information
and order tracking are often lower-risk datasets to open
up. They provide an opportunity to control API deployment
outside the enterprise in a low-risk environment, while also
strengthening the interdependence between a business and its
partners.

Partner APIs Help Scale Partner

Onboarding
Working with new partners and agents can create a lot
of additional administrative work. This workload is often
repeated with each additional partner or agent that is brought
on board. For example, businesses often work in partnership
with creative agencies to manage the brand and implement
marketing strategies. By sharing digital assets via APIs, a
business can ensure non-disclosure arrangements are agreed
upon, and that there is a commitment to following a brand’s
design guidelines. This also allows a creative agency to work
independently alongside a business. The terms of service for
a Partner API can include a non-disclosure agreement, and
2.2 Business Benefits of Partner APIs 33

the business can ensure that only defined branded content

assets are available via the API – thus reducing the amount
of ‘hand-holding’ a creative partner needs during the design
phase. This speeds up subsequent projects with the same or
other creative agency partners.

Partner APIs Enable Access to

New Customer Markets
Jeremy Glassenberg, Head of Platform Applications at busi-
ness network platform Tradeshift, an international startup
with a strong base in Denmark, says that “for our enterprise
customers, we provide standard features out of the box, but
then these customers have unique, one-off needs. So, for these
customers, in addition to open API connectors, we provide
them with a flexible API and supportive code to build a
custom integration.” By doing this, Tradeshift can leverage
the relationship with their business partners to offer services
to their partner’s customer base. For example, by providing
Partner APIs that allow Tradeshift’s services to be seamlessly
integrated into their partners’ financial and ordering systems,
their partners’ customers can make use of Tradeshift services
from within their existing operational systems. For Tradeshift,
a whole new market segment is reached.

Partner APIs Improve External

Communications
Businesses can also use Partner APIs to integrate their team
collaboration tools so that communication with external part-
2.2 Business Benefits of Partner APIs 34

ners is as reliable and consistent as with internal team mem-

bers. Some businesses use Software-as-a-Service (SaaS) tools
such as Salesforce, Podio, Basecamp and Trello to manage
joint projects across business boundaries. The APIs of these
SaaS tools can be used as a type of Partner API that allows
integration of shared collaboration tools into each business
partner organisation, while also controlling what information
is made available through the partnership.
Other businesses use APIs created for their proprietary soft-
ware that can build an external communication flow. For
example, this could provide for access to shared project man-
agement calendars, common datasets explaining project re-
sources, or procedural guides.

Partner APIs Automate Industry

Regulatory Requirements
At Norwegian life insurance company Storebrand, the prob-
lem is not just integrating to match the specific needs of
their business partners, but requiring the APIs as tools that
can integrate with partners, while recognising the insurance
sector’s specific legislative and regulatory requirements. An
additional complication: they must meet requirements that
may differ in each of the countries where their partners are
operating.
Terje Borgen, Platform and Integration Department Manager
at Storebrand Life Insurance describes some of the challenges
in setting up Partner APIs:

The main issue is connecting to a partner that does

a B2B connection for the first time. Other issues
2.2 Business Benefits of Partner APIs 35

may be Nordic script in certificates, and insurance

certificates that may need to be progressed through
a number of chains (that is, more than one legal
chain).
In Sweden, there is an standard called SSEK that
describes both the message headers and the secu-
rity setup that is mandatory for communication be-
tween insurance companies. In Norway, it differs
more from solution to solution. But there, two-way
SSL and XML signatures seem to have become a
standard for most APIs.

For Storebrand, using Partner APIs is reducing the regulatory

burden when working with partners across different regula-
tory frameworks in different countries. Once a Partner API is
created that addresses the specific regulatory and legislative
requirements in one country, Storebrand’s partner relation-
ships can focus on providing services and building quality
products, rather than repeating potentially error-prone and
burdensome regulatory processes.

Partner APIs Identify Commercial

API Opportunities
In many cases, monitoring a partner’s use of business infor-
mation can help identify new commercial opportunities. This
may become apparent in a number of ways.
For example, Tom Burnell from Axway also refers to how
Storebrand has used Partner APIs to extend their market
reach. A business partner has been able to leverage Store-
brand’s data via APIs as part of creating a health insurance
2.2 Business Benefits of Partner APIs 36

price comparison website. This website is now a source of

new business for Storebrand. The business partner is able to
provide a valuable service to its customer base by cutting
down the research customers need to undertake to compare
insurance products. As for Storebrand, they are able to demon-
strate how favorable their products are to a harder-to-reach
customer market segment.
For Finnish software provider PlanMill and Danish software
provider Kapow Software, seeing how partners were using
API integrations in their business systems was a valuable
insight into what the software providers could suggest to
other partners and customers as possible use cases. In both
cases, PlanMill and Kapow have also been able to create new
product offerings in partnership with some early adopters of
their Partner APIs.
Swedish online retailer Fyndiq initially opened their product
catalog via an API to a small selection of partners. This helped
them identify some shortcomings with their overall business
model. Rather than aiming towards the boutique market, they
saw how their partners were making use of their API and
realised they could provide a greater selection and range of
products to the market. After seeing how the Partner API
generated increased sales volume, and having confidence in
the robustness of their API product, Fyndiq was able to move
towards opening the API to third-party developers. These
developers were treated as additional partners in the business’
ecosystem.
2.3 Partner API
Challenges: User
Authentication to
Manage External
Access to Data
Partner APIs need to be designed with the same levels of
security that should be used for robust Public (open) APIs.
This also makes it easier to mature and grow an API when
businesses want to start opening up their Private and Partner
APIs to a wider developer audience. Travis Spencer, CEO of
Twobo Technologies, advocates for businesses to use the Neo-
security Stack to safeguard all of their APIs, including those
to be used with business partners.
“In an increasingly social, mobile, and cloud-enabled busi-
ness environment, data and user interaction must be man-
aged across the entire supply chain,” Travis says. “When this
flow of information is between partners across organisational
boundaries, security systems should not require that the end
user is continuously prompted for usernames and passwords.
Instead, organisations should rely upon a set of technologies
known as the Neo-security Stack, which delivers a framework
of open standards.”
Travis explains that at the base of this suite of protocols is

37
2.3 Partner API Challenges: User Authentication to Manage External Access
to Data 38

OAuth 2 and OpenID Connect. “These technologies allow

businesses that are creating Partner APIs to construct systems
where users can authenticate themselves and access specific
data and business functions that are in line with their roles
and access rights.”

David Gorton, Product Manager at identity management

security provider Ping Identity, explains how authentication
and authorisation ensure data security when deploying a
Partner API:
“There are two parts to OAuth. The first,” he explains, “is
around the issuance of a token that represents a user who
has authenticated. The other is when that token is submitted
to an API and the provider must determine if the client
should be allowed to access the requested resource.” David
adds that, “identity management and user authentication are
like providing keys to unlock your house, but they still let
you control where in the house your guests can go. In the
enterprise, you need to leverage federation and authentication
protocols to let business partners access your APIs. Alongside
this, you also need a robust auditing framework in order
to show compliance with any industry regulations and to
2.3 Partner API Challenges: User Authentication to Manage External Access
to Data 39

demonstrate adherence to security standards. Using existing

identity management standards allows increased adoption,
reduced risk, interoperability, and flexibility.”
David says that, currently, most industry players with an eye
for best-practice identity management and user authentica-
tion are emoloying OAuth 2 and SAML. While the emerging
standard OpenID Connect is still seen as “the new kid on the
block” by many, however, it is now being implemented by
Google, Salesforce, and many others. This increased adoption
is part of the reason it is expected to become the preferred
federation protocol over SAML in the not-too-distant future.
Neo-security frameworks put in place for Partner APIs can
also be used with Public APIs. In fact, in some cases, the
Partner API can be opened up to a wider audience, perhaps
just by setting stricter access rights than partner users are
granted. So, enforcing neo-security is not an impediment to
scaling a business’ API strategy, but should instead be part of
a solid foundation that makes growth possible.

Additional Resources
• Twobo Technologies Neo-security stack
• Ping Identity blog
2.4 Case Study: LEGO

Danish toy-making phenomenon LEGO uses APIs with se-

lected partners in order to best manage the way customers log
into their LEGO accounts, creating a seamless portal whether
customers are entering directly at a LEGO website or via a
partner website.
LEGO’s API maturity journey is somewhat unique. The need
for an API emerged in business discussions with their video
game partners, Warner Bros and Funcom, who were creating
LEGO-themed video games compatible with a range of de-
vices from Microsoft, iPad, and for the web.
“It has always been a business decision that when someone
has to log into any LEGO system, they should only log into

40
2.4 Case Study: LEGO 41

one system…, so that’s why we started collaborating,” Dennis

Bjørn Petersen, Platform Architect at LEGO explains. “In that
way, we ensure we know what sort of information we are
collecting from users, as we are often working with children
under thirteen, and being clear about what information is
collected is crucial for us,” Dennis adds.
Around the world, many countries have strict regulations
about what data can be collected from children using the
internet, and this is not a data responsibility that LEGO takes
lightly or would consider passing on to a business partner to
be responsible for. Dennis says this is not a reflection on any
of their business relationships but that “it is in our mutual
interest that this is covered by us.”
As work on the API design progressed, the company was
also looking to upgrade its own ‘LEGO ID’ identification/au-
thentication processes. Dennis’ team immediately saw the
benefits of using the API they were creating for internal
authentication processes as well. In this way, the Partner API
came first and led to it being used as a Private (internal) API
by the company as well. “So we decided we may as well create
an API for both external and internal developers. It is used in
games, on our message board, in our rewards program. It’s
used everywhere you need to log in with a Lego ID,” Dennis
says.
2.4 Case Study: LEGO 42

While LEGO is a global organisation, the toymaker-turned-

API-provider has to date been able to manage the API through
a series of resource-light tools and approaches. Dennis shares
some of the simple strategies they use in their partnership and
internal work:
Documentation: “We have created a JavaScript API; we
created a small test site with examples of snippets of code
that you need to add.”
API metrics: “We really don’t track our API use at the
moment. It is a manual process if we do. We are still looking
into usage metrics, we can see that usage is increasing, so we
are looking into an API management tool to take the load off
our backs.”
Error logging: “We do have an error logging tool, so we mon-
itor that, but luckily we aren’t big enough that people don’t
know how to get help. There are only about 100 developers in
the organisation so people know who to contact if they need
help. We do like to keep an eye on how our API is being used
2.4 Case Study: LEGO 43

and if it is being used correctly.”

Mentorship/pair programming: “When working with exter-
nal games developers, we normally do a code review, and we
send one of our developers to sit with our external partners
and work on the first integrations. It’s not that our API is
complicated, its just that game developing is different to web
application development, so it is just easier and faster to sit
with them.”

Key Lessons
• Start with low-hanging fruit: identify the data or ser-
vices that you regularly communicate with partners,
suppliers and agents
• Track usage metrics: at a minimum track API calls
made, error messages sent and, if possible, find out how
partners are integrating the API into their systems
• Make your developer team available to sit with external
developers using a ‘pair programming’ or other mentor-
based methodology when external partners first start
using your Partner API.
2.5 Reflections
• Can you open up your product catalog or a service
directory via an API with selected partners?
• What dataset(s) would be referenced when working
with business suppliers, partners and agents? What in-
formation is most often requested by partners and how
is this currently provided?
• Who is considered your most valuable partners? Who
manages these relationships? What do these relationship
managers - and the partners themselves - think would
be most valuable to open up as a shared resource via an
API?
• What regulation guides your industry? What specific
tracking must you perform to ensure communications
are documented as required, or that shared information
is stored correctly? How is this currently done and
can this process of ensuring authorisation of shared
information and storage be done via an API?
• What customer market segments do your partners pro-
vide services to? What services or products would you
like to offer to these customer segments? Can you pack-
age your products and services is a way that allows your
partners to be the front-end for making these available
to their customer segments?
• What metrics will you need to put in place to monitor
the commercial opportunities that might be available if
you open Partner APIs to a wider audience? What API
resources are requested most often? What are the use

44
2.5 Reflections 45

cases that your partners are implementing via your API?

What resources are seeing the greatest increase in use?
For what reason?
• Are there cloud-based software tools that you are cur-
rently using in your business? Do you use their APIs
to integrate the software with your legacy systems and
databases? Do you use their tools to integrate use of the
software with external teams?

Additional Re-
sources
• Why everyone speaking “Apish” makes
your whole business more agile, by Mar-
jukka Niinioja of PlanMill
• Who Cares About APIs? by Anne-Sofie
Nielsen of Kapow Software
3.1 Overview: Building
a Platform and
Ecosystem with Public
APIs

One of the biggest challenges facing businesses today is the

need to move towards a platform and ecosystem model. This
is the natural extension of becoming a “composable enter-
prise” model. In a composable enterprise configuration, a busi-
ness makes its services and data available in a components-
type of format so that external businesses and customers can
plug directly into the services and data they need for their
own value chain.
Instead of businesses creating products with a perceived end
value in mind, businesses open up their services and assets

46
3.1 Overview: Building a Platform and Ecosystem with Public APIs 47

in a way that allows end customers to create the value they

want.
As a result, businesses are transforming into platforms that
enable other businesses and customers to create the value
they want, using (and paying for) resources directly. Public
APIs are speeding up this transformation and extending a
business’ value base beyond its traditional markets. Facebook,
Salesforce and Twitter have been able to leverage exponential
growth by letting third-party developers and customers create
new products and services by using their Public APIs.
The composable model also enables a business to commercial-
ize the investment it has made in some of its own processes
and capital. In the same way that Amazon allows customers to
store data on its web servers – thus creating an opportunity to
monetize its investment in building large data servers – there
may be previously income-neutral aspects of a business that
can be opened up in a similar way with an API. Businesses
that carry out large scale data processing, for example, are
leasing access to this analytics power to others who need such
services, and this is often enabled via an API.
Other businesses are selling access to their research database
using APIs. Previously, this had been a resource cost that
other businesses had to pay to carry out its core functions.
Now firms supplying the data are able to monetize this cost
by making the research available to third parties via an API,
and the recipients are able to save time and money.
3.1 Overview: Building a Platform and Ecosystem with Public APIs 48

Building a Scalable Public API

Strategy
One of the greatest benefits of starting with Private and
Partner APIs before moving to a Public API strategy is the
ability to see what data and services are being consumed, and
what internal resources this consumption has in common.
While it is beneficial to start with an individual use case
when first considering the benefits an API may bring to a
business, it is important to then widen this perspective. It’s
important to consider what other use cases may be relevant,
and what datasets or service functionalities these use cases
have in common. This prevents building an API for each use
case, and avoids the risk of having multiple APIs all calling the
same dataset in only slightly different ways. When moving to
a public API strategy, it is important to have already mapped
the underlying data model that is being exposed to ensure that
any public API is scalable.
A key tactic to ensure that any public API created remains fit
for its purpose is to use it internally as well. Andreas Krohn,
Principal at API consultancy agency Dopter AB, encourages
businesses to “use public APIs internally.” Andreas gives two
examples of testing the value of a Public API: “If your API
isn’t good enough to use even as a widget on your website,
you need to rethink it. If you are still doing SQL queries down
into your database instead of using your API, you need to
rethink your public API.”
3.1 Overview: Building a Platform and Ecosystem with Public APIs 49

Replicating the Customer Reach

Lessons from Partner APIs
One of the benefits of Partner APIs is the potential to reach
exterior established customer markets. As described in section
2.2 above, businesses are able to almost ‘white label’ their
services and products via an API so that key partners can offer
these services to their customers with a sense of ownership.
In this way, Partner APIs enable a business to reach new
market segments that may have been difficult to connect with
previously.
When this strategy has begun generating new sales revenue
and is shown to have had success in a business’s operations,
the natural extension is to widen the reach by making this
Partner API available to third party developers. This can be
done in a controlled manner or in a completely open manner
depending on how a business has defined the risks to its brand
reputation, or the value of the data and services it is opening
up.
Some businesses widen the API reach to any third-party de-
veloper. The API itself is monetized so that developers pay for
the number of API call transactions above a certain threshold.
Often, a free level of access is provided to demonstrate the
value of the integration, and to assist third-party developers in
ramping up their customer base before having to pay for data
access. This is usually referred to as a “freemium” business
model.
Other businesses choose a semi-public API. While documenta-
tion may be public, rather than allowing open access, providers
may request specific details on how the API will be used.
Services like Pinterest and Twitter, for example, use this
3.1 Overview: Building a Platform and Ecosystem with Public APIs 50

approach as a way to curate how their brand appears in

third-party applications and websites. This approach often
necessitates more sophisticated business models, including
revenue sharing models, and affiliate commission-like agree-
ments. Businesses may test multiple revenue models to see
what is most appropriate for the resource(s) being exposed.

Special Note: Creating a Business

Around an API-as-a-product
APIs are also facilitating the creation of entirely new busi-
nesses where the API itself is the product. This is the case
with Twilio, for example. The Twilio API enables access to
SMS and now VoIP services, and is offered as a product to
other businesses. The API is a hybrid between a Partner and
a Public API as it is open to any third-party developer, but
those who integrate the API into their business functions are
often akin to partners as well as customers.
At its onset, Twilio began with a Minimal Viable Product
(MVP) and iterated the API features based on customer de-
mand. At Nordic APIs events across Sweden, Denmark, Fin-
land and Norway in April 2014, Ben Nunney, European
Marketing Director for Twilio, provided a number of insights
into Twilio’s growth and shared several use cases.
An innovative example involves Internet of Things (IoT)
technologies. Nunney showed how Coca-Cola’s vending ma-
chines perform self-diagnostics. When repair problems are
identified, the vending machine automatically looks up avail-
able repair contractors in the local area and sends a text via
Twilio to submit a service request detailing the malfunction.
3.1 Overview: Building a Platform and Ecosystem with Public APIs 51

Copenhagen-based shipping API startup Shipbeat has also

been deploying lean methods to offer a public API. According
to Shipbeat Co-Founder Kenneth Svenningsen, throughout
his current and previous ventures, “there was a significant
need for deep integration of multiple shipping providers to
automate processes, improve customer experience and to
reduce cost.”

“If the e-commerce company is active in multiple

markets, then they need to work with even more
shipping carriers. In both cases, we were looking
for solutions externally here in Europe and we had
a hard time finding something matching our needs.
Thus, after some time my co-founder and I con-
cluded it was time to build this service ourselves,
as we believe we have a validated customer need.
“When online companies implement payment solu-
tions, they do it through a service that aggregates
multiple payment options – no one builds their
own solutions for this from scratch. Secondly, we
have observed how the payment industry online
is moving from old school and legacy payment
solutions like DIBS in Scandinavia to solutions
like Stripe, Braintree and Paymill. We believe that
the shipping solutions for e-commerce companies
must follow the same trajectory”.
“So for shipping, the following must happen: first,
shipping services and partners (local and global)
should be accessible through one service, and sec-
ondly, this service should be very developer/user
friendly to allow easy implementation and manage-
ment.”
3.1 Overview: Building a Platform and Ecosystem with Public APIs 52

As did Twilio, Svenningsen is first focusing on a minimum

viable product for their Public API:

“The API is currently a prototype. Our goal is to

get it to an open public state very fast. The criteria
for when this can happen is based on two main
factors: - The API needs to be tested with an actual
customer to our customer’s satisfaction. It needs to
be confirmed as working and fit for real life need
and use cases. - The documentation needs to be
written in a simple form where we can confirm
that developers are able to understand it and able to
start using the API based on this documentation.”
3.2 Business Benefits
of Public APIs
Creating a Public API is often a key turning point for many
businesses. It is a time that is both filled with dread (that some-
thing will go wrong) and of immense hope (that transforming
the business will create new market opportunities).
Building Public APIs from the successes of Partner APIs
typically speeds up the growth curve of generating benefits.
However, many providers may not realize success immedi-
ately, and any benefits may take a little time to become
quantifiable. That is why it is important to communicate the
longer-term benefits of Public APIs with an enterprise’s C-
level.

Public APIs Automate Processes

Using other business’s Public APIs (and open data APIs) can
help a business automate processes and develop better deci-
sion-making workflows. For example, a business can use the
Public APIs of Zendesk, an online support desk service, and
the Public APIs from Twilio, the messaging service, to create
a business workflow where new customer service requests
are automatically directed to the appropriate business team
— and any priority customer requests are sent via text alert to
a manager.

53
3.2 Business Benefits of Public APIs 54

There may be opportunities for a business to open up its

own internal workflows or data in a similar way with a
Public API, so that this can be integrated into customer-facing
applications and user interfaces. For example, a business
could open its risk management intelligence data-gathering
systems for third-parties to consume and embed within their
own decision-making processes. In this way, the provider
can extend data that has been collected for its own use
to consumers to purchase and implement into innovative
applications.

Public APIs Improve Customer

Experience
Public APIs are tools that help respond to one of the greatest
challenges today for business: the segmentation of customer
markets. Each customer expects a personalized experience,
and businesses are losing the economies of scale advantage
— that of providing a generic product or service for everyone.
Current market expectations are that businesses should be
able to provide a relevant, personalized experience to each
customer.
APIs enable a new balance of both providing generic prod-
ucts and services, and personalizing the experience by using
contextual and user information to increase engagement. For
example, Public APIs make it possible to identify a user’s
previous preferences (such as an interest in family-oriented
content or services) and combine this with information about
the user’s current context (for example, whether they are
using a smartphone or desktop). Content can be remixed to
best suit the environment and personality of the end user
3.2 Business Benefits of Public APIs 55

(such as serving up the most recent content that other family

customers viewed, formatted to the appropriate screen-size).
Deploying APIs can help build loyal customers by delivering
a satisfying, personal experience.

Public APIs Reduce Costs

Public APIs can reduce the cost of new market entry by lever-
aging third-parties who already have access to key customer
markets and industry relationships. The wearable technology
sector is an excellent example of how this is playing out
with the availability of Public APIs. Wearable tech like health
monitoring devices may want to enter markets like extreme
sports users, leisure golf retirees, or soccer moms.
In the past, each of these demographics has required invest-
ment into separate marketing strategies aimed at reaching
these target customer segments. A wearable tech business
can now release an API and encourage third-party developers
who specialize in building applications for each of those mar-
kets to create an application that uses the business’s device.
Reduced costs can also be seen in how telecommunications
have leveraged value-added reseller markets to promote and
share new product streams. Selling prepaid mobile phone
packages, for example, has reduced the cost for telcos to
market and distribute this service. They have done so by
releasing Public APIs that allow resellers to more easily offer
customers this product directly from their product catalog and
services.
3.2 Business Benefits of Public APIs 56

Public APIs Integrate with

Flexibility
Public APIs reduce the need for creating an individual solu-
tion for each consumer. The costs associated with creating
a customized integration are moved onto the developer con-
suming the API. Instead of a business, for example, having to
pay the integration costs associated with connecting a third-
party to their accounting system for managing payments and
commissions, they can instead provide access to payment
processing via an API. The end user then has the flexibility
to integrate that API into their preferred system, while the
business provider avoids the costs associated with providing
a specific integration to each end user.
Noting how customers are integrating with a Public API also
suggests use cases that can be promoted to other customers
and partners. In response, a robust Public API should be
flexible enough to be incorporated into various development
environments.

Public APIs Provide Global Reach

(To Suppliers, Channels, Markets)
Micael Widell, CEO of e-commerce vendor Fyndiq, shared
with Nordic APIs an interesting example of how he has
chosen which APIs to integrate with his business. When
selecting a fraud prevention service for his e-commere startup,
he was researching online after hours. This was an important
task, causing Micael to work over the weekend to source the
best solution.
3.2 Business Benefits of Public APIs 57

As such, he chose a business supplier that offered the service

with a Public API that could be tested and integrated imme-
diately — over the weekend — and which was supported by
user-friendly documentation.
Working in a global marketplace, businesses can miss out
on opportunities if they are perceived as being unavailable
outside their home country working hours. This ‘round-the-
clock’ capability is something that key international busi-
nesses in such environments as the Nordic region – and
increasingly amongst southern hemisphere-based businesses
such as Australia and New Zealand – are using to their
advantage.
Public APIs can provide 24/7 access to global markets. This
empowers customers from across the globe to access a busi-
ness’s products and services whenever they are required,
customizing their needs using open API documentation and
accessibility.

Public APIs Increase Customer

Lifetime Value
Public APIs build customer loyalty. Once an API is integrated
into a customer or third-party developer’s value chain, they
remain as customers for a longer time, and are generally
happier with their experience.
There are, however, some caveats with Public APIs. It is easy
for customer trust to deteriorate if an API changes frequently.
Once an API is integrated into a customer or developer’s
applications, systems and interfaces, it is troubling if there are
constant error messages, or if the API ceases to work entirely.
3.2 Business Benefits of Public APIs 58

To maintain customer loyalty, businesses providing a Public

API need to clearly communicate updates and keep transpar-
ent change logs. In some cases, it may be best to support
multiple versions of a Public API to maintain customers on
earlier integrations while newer customers access the latest
version. When an older version of an API is to be deprecated,
it is preferable that you schedule a timeline for adjustment,
and provide multiple messaging points to alert existing users.
It may also be possible to ensure that newer versions are
backward compatible, so that for long-term customers, there
is no noticeable difference when a business upgrades to a
newer version of its API.
For many initial API users, a Public API integration can
be a ‘set and forget’ experience. Once the integration is
established and any initial learning bumps are resolved, the
API can be used consistently in an end customer’s workflow.
This can create an ongoing revenue stream for the provider.
However, changes to an API terms of service must be clearly
disseminated to the community, as any new versioning put in
place that alters the way API calls are made can break older
use cases and bring revenue to a grinding halt.
3.3 Public API
Challenges
While Public APIs do create many new market and revenue
opportunities, they may fill businesses with dread. This is
due to the risks associated with exposing internal data and
services with an API. The mere attention drawn to a business
with a Public API may lead to attempts at gaining access to
private data through insecure API gaps.
Using a federated authentication system as part of a neo-
security stack (as described in section 2.3) is an important
foundation.
However, merciless hackers may still target a business’s
Public API merely because it is publicly available. This is often
done to access social media accounts to use for spam adver-
tising. Unfortunately, there are also an increasing number of
attacks on businesses. APIs are being used as a gateway in
attempts to gain access to customer passwords.
The social media tool Buffer found that by having a Pub-
lic API they became a target for hackers trying to break
into their systems. A forensic analysis of their 2013 security
breach showed that hackers reviewed their documentation on
GitHub multiple times trying to identify ways to access the
API without an authorization key. After they had managed
to breach Buffer’s API keys storage, they then had access
to encrypted information. The hackers then tweeted to ask if

59
3.3 Public API Challenges 60

anyone knew how to un-encrypt that particular type of file!

(Maybe this gave them away).
The challenges of security never disappear, and as more
businesses make use of Cloud and web-based services, these
risks will continue to grow. It is not within a business’s best
interests to manage all of the potential security risks that arise
from opening a Public API. Instead, it is necessary to work
with a trusted supplier whose specialty is solely in security
systems for APIs. Even when this is the case, regular security
audits and having internal experts scan for potential security
risks are still essential elements of a robust Public API work
program.
A second challenge facing many internal API architects is the
need to quickly demonstrate the returns on investment.
The time-to-return on investment can be longer than many
businesses prefer. After all, there are two growth curves
that need to be realized in order for a Public API to begin
generating revenue opportunities.
First, there is the growth period in first establishing a strong
community of developers integrating the Public API into
their applications and web services. There is then is a second
growth curve where those third-party applications and web
services must establish their own end-user customer base.
It is important to have interim metrics that indicate how bene-
fits will be reached. Using Public APIs internally to automate
processes is one area where a strong business case argument
can be demonstrated to show the productivity cost savings
generated by using the API. These internal cost-savings can
be used to demonstrate sustained investment in a Public API
program, while awaiting revenue growth from the third-party
developers using Public API offerings.
3.4 Case Study: Podio

How Podio’s Success Depends on

Third-Party Developer Success
Podio is a Danish cloud software company that has built
interchangeable widgets for business-specific workflows and
processes. Customers can create dashboards and project man-
agement toolkits for their HR, marketing, sales and finance
operations. As a bonus, Podio can be used to oversee all stages
of a particular project, such as new product development.
Podio’s clients range from startups and independent contrac-
tors to enterprise customers wanting to use a composable
project management software system that is flexible enough
to match their specific needs.
The Podio API is a Public API designed for two audiences:
> Customers can use the Public API to integrate their Po-
dio workspaces with their existing enterprise and business
systems (this is similar to a Partner API, in that you must
already have a relationship with Podio to use the API in this
way,) > Third party mobile app developers can build and
commercialize new integrations and products using the Podio
API. The products created by these developers are aimed at
Podio customers as the primary target market.

61
3.4 Case Study: Podio 62

To help developers use the Public APIs, Podio provides a range

of support and educational materials including: - Immediate
API key registration - Tutorials - SDKs in PHP, .NET, Ruby,
Java, Python, Objective C and Mobile (iOS and Android) -
Video examples - Developer code for sample projects stored
on Github - Developer forums - A blog focused specifically
on developers using the API and SDKs - Showcase pages and
a marketplace webpage showing what developers have built
with the APIs.
Gustav Jonsson, Product Manager at Podio, shared with Nordic
APIs further details on two of the above strategies: making
SDKs available, and showcasing pages that demonstrate what
developers have built.

SDKs Speed Up Developer

Onboarding
Gustav sees the SDKs as an important pathway to help
developers get up and running quickly.
“We already have an active and dedicated developer com-
munity,” says Gustav. “SDKs are an important part of that
puzzle. It’s really about creating a seamless and easy way for
developers to get started with the API… we really saw the
potential for developers building a lot more on mobile, and
we wanted to make that a lot easier.”
For other API providers planning to provide SDKs for their
API, Gustav shared that “Historically PHP has had around
50% of the usage. With Ruby and .NET tied for second. We
haven’t really pushed mobile SDKs in the past and we’re very
much looking forward to seeing what people will build on
mobile.”
3.4 Case Study: Podio 63

The Success of an API is Measured

by the Success of its Users
Gustav shares: “I heard a quote from an executive at Amazon
the other day which said, ‘We want to build a platform to
make others successful’. I think this also sums up our approach
pretty well.”
To demonstrate this, Podio has developed a number of show-
case pages aimed at helping developers market the products
and solutions they build using the Podio API.
The Podio Extensions showcase contains example apps built
by third-party developers that can be connected to a Podio
customer’s existing account. These developers receive new
business by either selling their extensions to Podio customers,
or by using the extensions to market their services as a Podio-
accredited partner that can help businesses optimize the use
of Podio in their operations.
For example, Oval Business Solutions offers free apps like the
Timeline for Podio. While this integration is free, when you
click on the business link, you are also referred to Oval’s home
page, which offers business consultancy services to make best
use of Podio in your business workflows and processes.
Meanwhile, Danish developer shops like BendixKiel and Phases
are building ‘freemium’ or paid apps that use the Podio API,
and marketing them to other Podio customers via Podio’s
Extensions showcase webpage.
“There are multiple ways that extension developers are charg-
ing for their products at the moment,” Gustav adds. “We
acknowledge that there could be multiple ways for the people
3.4 Case Study: Podio 64

using Podio to pay for the extensions. For example, a doc-

ument printing extension might have a credit-type system
where you pay for usage, while a Gantt-chart extension
charges for the amount of users of the extension. We think
that giving this freedom to the developers is a good thing,
since they can be flexible in the ways that they’d like to
charge. We want to share data with the developers on what
model is most efficient, and that’s in our plans for the future.”
At present, while Podio builds up the developer ecosystem,
API calls are free of charge. Although, Podio has begun
metering API usage and “are looking at revenue share for the
near future,” confirms Gustav.

Key Lessons
• Build quality support materials including tutorials, videos,
and clear API documentation.
• Help third-party developers commercialize off your API
by helping market the products they develop with your
API.
• Consider the use of SDKs in relevant coding languages
to help speed up initial third-party product design.
• Offer a free version of your API to ignite your developer
ecosystem, but start metering and measuring usage so
you can see when it is time to introduce a revenue-
sharing business model.
• Collate data on how third parties are leveraging the use
of your API to generate new income. Be open to sharing
an analysis of this data in aggregated form to help third-
party developers identify the most viable business model
for their API usage idea.
3.5 Reflections
• What Public APIs can be used from external sources
(e.g.. from partners or available in SaaS products used)
that can generate productivity benefits and demonstrate
business value?
• What Partner APIs are used regularly or at high volume?
What are the use cases in which partners are using these
APIs? Do similar use cases exist for customers and third-
party developers?
• Can any of the following datasets be opened up with a
Public API?
– product catalogues
– customer preferences
– historical purchases
– logistics information
– seasonality of products and services
– location of historical purchases
– user recommendations
– services providers and networks?

65
4.1 Conclusion: The
Roadmap from Private
to Public APIs

There are many pathways to API creation and design. Some

businesses might start with Private APIs and then make them
public (though this is rare). Others may jump straight in and
start creating an open API (this is quite often the norm).
In any case, Ronnie Mitra, API Advisor with API management
company Layer 7/CA Technologies urges businesses to ensure
that basic API infrastructure is in place — and built with
best practice principles in mind for Private and Partner APIs

66
4.1 Conclusion: The Roadmap from Private to Public APIs 67

(features like an API security gateway, a developer portal

and API instance), so that if a business does decide to open
up more broadly, they are robust and secure enough to be
accessible and usable by third-party developers.

Experiences from the Partner to

Public API Journey
One strategy is to start with a Partner API and move to an
open API when the business feels confident enough. This is
the approach taken by Marjukka Niinioja, Senior Consultant
and Manager at Finnish software company PlanMill, and also
by Peter Jervgren, head of Strategy & Architecture at the
Swedish offices of international energy company E.ON.
While both businesses have a significant online presence, they
are also both firmly rooted in working in more traditional
business sectors, where their partners and customers may not
be quite as API-conversant.
PlanMill is a Software-as-a-Service platform for businesses
complete with components like CRM, invoicing, and project
management. Their customers end up storing a lot of their
business data in the system.
As Marjukka explains, “If you are our customer, you can
use our API free or almost free-of-charge to connect to any
of your own systems or to 3rd party systems. You can also
give access to any of your customers and partners to access
your system via the API. We do also let companies we are
interested in becoming our partners to use the API,”.
For energy and utilities company E.ON, Peter Jervgren says
they are just getting started with Partner APIs, but have
4.1 Conclusion: The Roadmap from Private to Public APIs 68

a ‘semi-open API’ in their sights. “At the moment, we are

focusing on internal and Partner APIs,” Peter says. “However,
E.ON acknowledges the user empowerment that comes with
open APIs. E.ON wants customers and partners to be engaged
in the future of energy solutions. But, the ramp-up towards
open APIs will be done in a controlled way and according to
the directives of the E.ON business strategy.”
In both of these case studies, the businesses have started
with Partner APIs. After they learn how to implement and
manage the API with some external integrators, they will
move towards opening them up more broadly as Public APIs.
By working with their network of business partners first,
PlanMill has ended up with a suite of third-party apps that
help them connect with new markets. In some cases, they even
share the revenue generated from entering those markets with
their partners. The infrastructure is then tested and in place as
PlanMill opens up API access to new developers with whom
they have no existing relationship.
“Letting partners and customers create integrations them-
selves with very little participation from us would have been
totally impossible otherwise,” says Marjukka. “For example,
integration with Atlassian’s Confluence wiki or Jira was done
mainly by our customer Ambientia, and we are selling the
Confluence integration together. Also, we were able to give
Administer Oy the possibility to code purchase orders and
invoice integration with PlanMill, and our customer Futurice
built a complete time report mobile app and UI (FutuHours)
on top of our API. In terms of externalizing development and
shortening the time to develop things, an API is a must. Real-
time integrations just cannot be done with a file import or
export.”
4.1 Conclusion: The Roadmap from Private to Public APIs 69

E.ON is thinking along similar lines. Globally, in the final

quarter of 2013, energy and utility companies were the fastest
growing sector creating mobile apps that routed data on
energy consumption and usage from their APIs. “We think
that ‘Home Energy Management’ and ‘Smart Cities’ are two
examples where we can expect open APIs to soon emerge,” Pe-
ter confirms. “This is also in agreement with E.ON’s ambition
to stay at the front in terms of investments to keep our globe
and climate sustainable.”
One characteristic that both PlanMill and E.ON stress in cre-
ating open APIs is to have clarity around business workflows
and business logic. In many cases, it may be easier to resolve
these questions when building an API with partners first, so
that by the time it is opened to a public audience, you are
confident it is robust.
“The first thought in our business when talking about APIs
was that it was something techie and only an integration
layer,” Marjukka shared with us. “For many business users
and managers, it has been really difficult to think of it from a
business requirements perspective.”
“Lots of times, we get a request from a customer company
related to our API where a developer (usually fresh out of
school or making his thesis) has been given the task of ‘get our
time reporting and XYZ things integrated between PlanMill
and our X system’. They start to approach it as a programming
task only and then they realize that they need to actually
know a little bit of what is the process, where, when, how
are things being created, edited and deleted, and, for example,
which system is the master of the data. This brings us to the
question of the whole business process.”
In this case, PlanMill could work with partners to better
4.1 Conclusion: The Roadmap from Private to Public APIs 70

understand the potential use case, and get a real feel for
how the API would enable more efficient business processes.
This is valuable insight for identifying potential customer seg-
ments who may also find this type of integration useful, and
for communicating the value proposition to these customer
markets.
By deploying Partner APIs first, a business can also get a
feel for the support requirements that may be necessary to
manage a public release. “It has been — and still is — a huge
learning experience internally how to support, consult and
sell the API because it’s so different from our base products
with user interfaces,” Marjukka said. “Plus the development:
remembering that all the business logic checks done in the
UI need to also be done in the backend, because you have to
check data integrity.”
Peter agrees. “We try very early on to introduce Lifecycle
Management for implemented APIs. We think that a lot of
competence and experience can be obtained by adopting
best practice already present at the current line organization
within E.ON IT. The unit is handling IT Services at the macro
level according to the ITIL framework where service level
agreements, release and change management are fundamen-
tal ingredients.”

Moving to Public APIs

PlanMill are currently thinking through the ‘what ifs’ that
have become more concrete now that they have started their
API journey. As Peter asserts, “We are exploring possibilities
to open up more of our localization and other data to the
public, to customers who are not otherwise users of PlanMill,
4.1 Conclusion: The Roadmap from Private to Public APIs 71

although we will be requiring registration and most likely in-

troducing some amount of fees, possibly according to usage.”
E.ON is moving their Partner APIs to a semi-public type of
access: “We think that we will start to introduce semi-open
APIs to large customers and key accounts. These customer
categories typically have a close partnership with E.ON so
there can be a fruitful ‘give and take’ situation. All parties can
benefit from an agile and refactoring style of development.
E.ON is also participating in the EU initiative Finesce that
is targeting the Future Internet for Smart Energy including
machine-to-machine (M2M) communication and the Internet
of Things.”
However, Peter concludes that like any business opening up
its APIs, E.ON points to a key discussion that needs to be
resolved internally: “Our key considerations are related to
security and intellectual property rights. Given that future
E.ON Energy Solutions will include more IT-related services
and many of these services will be aggregates of third-party
services E.ON needs to ensure that exposed APIs are robust,
secure and not violating any business agreements.”

Other API Maturity Pathways

Of course there are other pathways that businesses can nav-
igate towards opening up their APIs. This can include com-
pletely separate API journeys. For example, Private APIs may
stay private and for internal use only, but the experience
can give a business more confidence and practical knowledge
when identifying other services or datasets that might be
more suited to a Public API audience.
4.1 Conclusion: The Roadmap from Private to Public APIs 72

In some cases, it may be possible to expand a Private API to

Partner, and then to Public. The examples given in this e-book
that relate to product catalogs and order tracking are suited to
this maturation, as is the opening up of such data as branded
digital assets and store locator datasets.
Which API maturation pathway is best suited to a particular
business is something that each business must decide. The
strategies and case studies outlined in this e-book, along
with the interactive exercises at the end of each chapter, are
provided to help your business with this journey.

Reviewing API Types

Private APIs can help increase internal productivity and cre-
ate efficiency savings across a business’s operations. They can
also help speed up time-to-market for product development
and encourage greater cross-departmental collaboration.
Partner APIs are strategically shared in a B2B agreement.
They can help strengthen external relationships and widen
a business’s reach to encompass partner customer markets as
well.
Public APIs are open APIs, and can help a business monetize
its data and capital assets, enter new markets and create new
revenue streams.
All three API types have their own benefits, but can also
create a multiplier effect when used along a pathway of API
maturity. Most important of all is that API usage in a business
assists in reorienting the business culture and mindset to-
wards a platform model and ‘composable enterprise’ identity.
This mindset is essential for stability and success in today’s
economy and emerging business environment.
4.1 Conclusion: The Roadmap from Private to Public APIs 73

For More Nordic APIs…

We look forward to hearing your experiences at future Nordic
APIs events and in the Nordic APIs forums, including on
Twitter @NordicAPIs, in our blog (use #NordicAPIs and
#APImindset hashtags to share with our community), in our
LinkedIn group, and by providing feedback to our newsletter
team.
Endnotes
• User Experience Honeycomb by Peter Morville
• Identity-related Venn diagram by Gunnar Peterson
• LEGO bricks by 713 Avenue

Nordic APIs is an independent blog and this publica-

tion has not been authorized, sponsored, or otherwise
approved by any company mentioned in it. All trade-
marks, servicemarks, registered trademarks, and regis-
tered servicemarks are the property of their respective
owners.
Nordic APIs AB Box 133 447 24 Vargarda, Sweden

74
Endnotes 75