How Nordic Businesses are Choosing between Private, Partner and Public API Strategies

As Nordic companies take up an API business strategy in 2014, many are asking how open should their first foray into APIs be?

APIs enable businesses to shunt data and functionality across an organization and to its wider network of relationships with suppliers, partners and end customers. But it also risks exposing insecure access points, commercial-in-confidence intelligence, and can inadvertently grant free access to services for which there is a market willing to pay. Releasing an API can also have a long-term effect on customer loyalty that works both ways: while customers who use a business’ API are likely to spend more and remain a customer for longer, if a business changes its open API too much or too often, it can destroy trust with those customers who rely on the API access for some part of their supply chain.

Image: FABERNOVEL, Why Should I Care About APIs, December 2013

NordicAPIs will be addressing how businesses can choose between open (public), partner, and private APIs in our series of industry events to be held in Denmark, Finland and Norway in April, 2014.

Private API models

Swedish firm Bisnode is one company that has already considered the best way to use APIs across its business operations. Joakim Skog, Portfolio Manager Sales and Innovation at Bisnode, told us about how he started by introducing the idea of using APIs to power internal processes, that is private APIs:

“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.”

Skog continues by saying 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 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.” Skog 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 criticized, and the lesson there was that I wasn’t pedagogical enough. There are many misconceptions around APIs and when raising a topic like that in a company where the core asset is refined information, you need to first explain what APIs are before you can put it in relation to your line of business.”

Partner API approaches

To leverage business relationships in a cloud environment, companies are also beginning to turn to partner-based APIs as a way to collaborate effectively and to facilitate relationships from one business’ end-customer base to another. Swedish Digital PR agency Deportivo, for example, uses the APIs that come with Software-as-a-Service tools to facilitate partnership communication. In a recent interview on ProgrammableWeb, Art Director Arvid Dyfverman mentioned using APIs from project management tools like Trello and Basecamp as part of a ‘partner API’ approach.

Danish company Tradeshift provides a public API to help customers easily integrate business networking services into their legacy systems. But they have also created a library of partner APIs aimed at making it easier for their end customers to integrate with Tradeshift’s network of suppliers. For example, Tradeshift business customers can use the platform to more easily invoice Tradeshift’s partner suppliers.

Public API releases

Meanwhile, new Copenhagen-based startup Shipbeat is focusing on offering a public API as quickly as possible.

“I have worked in two medium-to-large e-commerce companies (Miinto and Rocket Internet) where there was a significant need for deep integration of multiple shipping providers to automate processes, improve customer experience and to reduce cost,” Shipbeat Co-Founder Kenneth Svenningsen told us.

“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 and here in Europe and we had a hard time finding something matching our needs. Thus, after some time my co-founder and I concluded it was time to built this service ourselves as we believe we have a validated customer need.

“When online companies implement payment solutions, 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 secondly, this service should be very developer/user friendly to allow easy implementation and management.”

Svenningsen explains how a public API is at the core of Shipbeat’s business model:

“The API is currently a prototype and we are setting up a test customer here in January. 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.”

Helping Nordic Businesses Define an API Strategy

Understanding and identifying the different benefits and limitations of public, private and partner APIs is a conversation currently being held amongst industry stakeholders, all around the world. Cyril Vart from French business consultancy FABERNOVEL has been talking to business leaders about the value of APIs for the past few years, but is finding that the discussion around public/partner/private APIs is more in line with what businesses need to know.

“The API use cases we share are really getting traction in the industrial world”, Vart told us. “If I come from a business that is not a pure player [i.e. is not a cloud-based/new tech business], then our API cases studies around private, public and partner make much more sense than, say, a LinkedIn or API story.”

In April, our events in Copenhagen, Helsinki and Oslo will help all Nordic businesses to manage a sustainable and effective API Strategy. We look forward to continuing the discussion here in our blog over the next few months, and with you and many other businesses at our next series of events.