In the first part of our look at Partner APIs, we laid out the “zero vision” to take when forming a partner API strategy. We also discussed the importance of targeting the low-hanging fruit that can enable B2B relationships to begin using APIs to improve communications and speed up the flow of information. In Part Two, we look at what happens when partner APIs are being used to foster ecosystem growth and strengthen collaborative networks around a business.

Many Nordic companies find it difficult to create scalable API infrastructure and avoid taking relationship-specific approaches with the APIs they provide to external partners. This challenge has by no means been solved, but innovators like Tradshift and Skandia are at the international forefront of experimenting with processes they hope will reveal new ways to conduct partnership on-boarding.

Listen and Learn

Tradeshift sees that for many partners, it all comes down to the ability to communicate around API needs. “It’s a people thing,” says Head of Platform Applications at Tradeshift, Jeremy Glassenberg. “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 support them on a technical level through development. What I found on any good enterprise 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.”

At Skandia, Dennis Skantz, Solution Architect at Skandia Norden feels that choosing and starting work with a partner on their API may well have been the easiest part of the process. Skandia’s first API partner was chosen to help the finance company make customer-facing mobile apps.

Now comes the hard part: “We have so much to learn, and we’re making those mistakes now!” Dennis points out how it is one thing to be reading API best practices and another to actually implementing a strategy with an external partner. He sees a need for events like Nordic APIs as they let businesses share their API experiences in a more practical manner than can be gleaned just from reading the industry experts.

Use the right tools

To add to Skandia’s challenge, Dennis has had difficulties finding the range of API management services that he could use in a composable way.

“There are a lot of API gateways, but they are all integrated with their own OAuth servers, for example. We didn’t want to mix the identity management layer with the API management layer. There should be an open protocol to communicate between an OAuth server and an API gateway. So we ended up picking our existing API gateway that uses SOAP services and tweaked that to manage REST protocols and have that integrated with our identity management.”

Now Dennis is facing a similar challenge in creating documentation for his partner API: “We might be suffering a little from not using a community platform for API documentation. But our decision was not to create a community platform for our API partner at present, we could have gone all in with an API management provider but then we would have had to use their OAuth server and what if their community platform is no good?”

While the lack of a community platform is hampering some efforts – at times they can be three iterations apart between what the API partner has documented and the version Skandia are deploying – but Dennis is confident that the lessons learned with working with their first API partner will help them understand how to collaborate with more partners in future.

Use metrics to understand partner usage

In the meantime, 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 when setting quotas seem necessary, more supportive techniques are available to improve the flow of data with business partners: “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, rather than having to set restrictions that limit the ability of connected apps and create more challenges for partners.”

Storebrand have a sophisticated measurement system in place, according to Terje Borgen, Platform and Integration Department Manager: “We have our own custom made monitoring system 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. He recommends businesses measure usage patterns and set quotas. By measuring partnership API usage, it may be possible to see new product development opportunities down the track. “For business partner APIs, you can still set quotas,” he says. “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.”

Building API documentation for partner APIs, the best metrics to use when measuring partner API usage, and opportunities to monetize off partner APIs will all be themes discussed at our upcoming Nordic APIs events in Stockholm, Helsinki, Oslo and Copenhagen in early April. Join us to discuss how to use partner APIs to empower your business ecosystems and to create new market opportunities.