Using specifically-designed APIs to work more collaboratively with partners can build trust in business relationships and enable 24-hour access to your business supply chain. But one-off API strategies can also be costly to produce and can challenge existing relationships with trusted suppliers and business contractors. In Part One of our look at partner APIs, we review some of the challenges facing businesses using partner APIs, and discuss a “zero vision” aimed at creating an API platform that can scale with additional partners in future. In Part Two, we talk about what metrics to analyze partner APIs and look at why a hybrid model of managing partner APIs may be necessary.

When starting with Partner APIs, VP of Product at Axway (a Nordic APIs sponsor), Mark O’Neill, 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,” he says. “Price catalogs, order status lookups, shipment lookups: B2B want ways to go in and look at these, so they are good candidates to have available to partners as an API.”

Beyond these more straightforward API use cases, identifying partner API opportunities often requires case-by-case communication and then monitoring of API access when a process is in place.

Jeremy Glassenberg, Head of Platform Applications at 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, you can provide them with a flexible API and supportive code to build a custom integration.”

At Norwegian life insurance company Storebrand, the problem is not so much the specific needs of their business partners, but the different insurance legislative requirements that may operate in different countries. 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 may be Nordic letters in certificates and certificates with difficult chains (more than one legal chain). Most of the time either we or the partner already have an API in place. So it’s up to one of us to implement according to an existing API. In Sweden, there is an standard called SSEK that describes both the message headers and the security setup for communication between insurance companies. In Norway, it differs more from solution to solution. But 2 WAY SSL and XML signature seems to have become a standard for most of the APIs. SAML SSO is something else, but this is normally even more easy to implement.”

Swedish banking and insurance group, Skandia, have different challenges, as they are working with partners who have not previously had an API, creating challenges for scaling their API 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,” Dennis admits, an experience that is sure to be common amongst many Nordic businesses. “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.”

Despite this previous experience, Dennis is confident that partner APIs are the answer. As a 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, who in turn may build customer-facing apps, for example. “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,” he says.

To manage how 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 depend 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 Part Two of our discussion on Partner APIs, we explore approaches to managing relationships and tracking partner API usage.

The Nordic APIs tour starting March 31st and continuing till April 3rd with stops in Stockholm, Copenhagen, Helsinki and Oslo will be one of the first international and regional opportunities for businesses to discuss how to use partner APIs to strengthen a business ecosystem and create seamless, collaborative communication systems that can power global business relationships. We really hope you will join us at one of these events and continue this discussion there. In the meantime, we’d love to hear your views in a comment below or on Twitter.