API Lifecycle Management

No API is an island, Driving product growth through a partner ecosystem


Erik Tveitnes is an API Lead at REA group. In this article, he discusses, “No API is an island; driving product growth through partner ecosystems.” REA Group is a leading global digital business working to change how the world experiences property.

John Donne, in 1624, wrote a poem, “No man is an island entire of itself; every man is a piece of the continent, a part of the main;” I think John Donne was a bit of a futurist because what he says is API, on its own is only an internal optimization for a business. But an API, acting in a network with all the other APIs in a tapestry of connection and interoperability, gives us great benefits, and that’s what we’re striving to do. My favorite example, that I like to use to explain this is Slack and Zoom are two tools that we probably all use every day. We can go to Slack and start a Zoom meeting. But these are two separate businesses that have a shared customer base. In some ways, they compete for the same market share. They would have had a boardroom decision and looked at the advantages and the disadvantages of partnering. They’ve come up with a solution that makes a stickier customer, a customer that wants to use both tools and will be more likely to stick with the tools that they have.

Case Study – Ignite – a customer platform. Our customers are real estate agents and agencies. Our consumers are vendors buying or selling their homes. Ignite goes out with a strategy of the channel of choice. We have our own experiences or web-native experiences that real estate agents can use. We also have an API channel, a way that customers can receive their data via an API. Prop-tech is similar to FinTech and deals with the property segment. Today, we’re at about 500 prop tech businesses operating in Australia, providing software services for anyone in the property market.

REA integrates with many of these partners to advertise to them. What we find is customers use REA as a supplier of advertising. This spawns the need for CRMs or central systems that a real estate agent will use to centralize their data across all portals.

This leaves us with an architecture for real estate. At the top, we have our residential, rental, commercial, and developer lines of business. They provide APIs that we push out to market. Those same teams will improve to build features with our own web app experiences. They will provide the same data to the prop tech partners, their customers down the bottom of the same real estate agent customers using either their own prop tech solution off the shelf or the native REA web and app experiences. We find different use cases. Customers prefer to use a prop-tech business for leads and listing advertising but may prefer owned experiences for campaign reporting or purchasing.

When we built APIs initially, we built one endpoint used by both external parties and our internal teams when building out experiences. The main reason is that it’s cheaper to implement a single endpoint. A team could only think about what they’re building once and how to make it available for everyone else. It’s a single thing to maintain for them as well. When they want to change something or build and test it, they can build and test it with their own experiences and then release it to the external market. The most important benefit is openness and trust; I can walk into a partner meeting, put my hand on my heart, and say that the same data we provide in our APIs is used in our own experiences. This shows Prop-tech markets that we’re not coming to steal their market share, instead, we’re giving a choice to our shared customers of how they do business with us. It’s been a very effective tool for that.

But as APIs have evolved, we are leaning towards separate external and internal endpoints. This is because it allows federating teams to test and learn quickly. By having separate endpoints, our teams can change our APIs because they own the front and back end and move forward. They can do versioning strategies for the external market and slowly release features in big bangs for partners to use. We’re also finding different use cases for our internal and external users; our internal users, via APIs, want to power websites, which means request-response to display data on the screen. Instead, Our external partners want a copy of our data in real-time, which can take time in the current strategy. We get better control of what we release. We have the ability to make decisions on what to release to partners and what to release internally when we have separate endpoints. Lastly, it’s easier to evolve. More importantly, it’s easier to retire our endpoints when we control internal and external, as we’re not waiting on the partners to make updates before we release something.

Partnerships and relationships are all there to help the adoption of our systems. If we get partnerships, we can get early adoption and feedback. Go out and excite our partners and say, look at what we’re releasing; please work with us to make this is success. Get feedback and fix problems. If you fail to do this, you get little to no adoption of your APIs. It would help if you found other ways to incentivize adoption of your APIs. We use things like cross-promotion opportunities to make it a success.

If you do partnerships, you get more opportunities to create shared experiences. That is to give the users a great experience in one tool or one system where they don’t have to jump around. You can provide them with your product value in another person’s system where the customer wants to work. If you fail to do this, you give the customer a bad experience. You’re curating them siloed experiences where they have to log into multiple websites to do what they need. This is a way to lose customers.

If you get partnerships work, you enable innovation outside of your business. If you do not have partners, you are limited in building features. But with partnerships, you’re opening up your data to the outside world to innovate and build products for your shared customers, meaning they’ll be stickier customers for longer.

It is important to talk to your partners about the benefits of the partnership. Talk about openness and trust with our partners about how we can deliver new things and our long-term goals. Because if they don’t trust you, they won’t come along for the ride. But if you can clearly articulate and show, with diagrams and pictures, what is in it for both of us, you get a lot better job at getting adoption.

You can ensure good adoption by following this list –

  • Getting a Win-Win is essential. You have to find that; otherwise, your market will not get the product; it will not get the adoption you want. It would help if you thought about what is in it for them to integrate and what they are giving up to do your integration with you.
  • You must identify the decision-makers and convince the managers. But more importantly, you must convince the developers inside that partner business because those managers you convince will go to their most trusted developer and check the feasibility.
  • Sell the story. You must speak in layperson’s terms. You must use diagrams and show the data and value-add but do not get too technical.
  • Be transparent and get the trust. Share the outages. Publish your roadmaps. Show where you will get people to understand that you are there to do business and do it openly and transparently.
  • Show that you are easy to work with. Appreciate feedback and, most importantly, show how you implement the feedback.
  • There is room for all of us to grow and do a better job. And we want to be easy to work with. We want to take feedback. But also, importantly, we want to implement that feedback. We want to show it’s a two-way street.

Is it spawning a competitor or cultivating innovation?

When you go into a business and start talking about APIs and products as APIs, you run into some headwinds within your business. At REA, we’re no different. We spent 20 years building websites and apps. We have built designed systems, integration platforms, infrastructure platforms, and platforms on platforms to optimize the way we build websites.

Some common things that come up when we build partnerships –

  • REA partners use our data on their systems. Looking at monthly active users on our channels as a success point may disincentivize our product teams to release data on our API channel. But that should not be the case. Our product is still sticky. Customers are still advertising properties.
  • Speed to market is important. When a team owns the front end and the back end, they can give clear estimates that are quick to market, and they can test and learn as they go. A partner ecosystem takes more coordination with an external partner and has to find time in their roadmap. It’s often slower and leads to friction when teams think about it.
  • Lack of partner system knowledge: we know our systems like the back of our hand, but we may not know all that our partner systems can offer. So, getting involved with your partners and getting diagrams and screenshots early can help convince your teams that the partner systems are the way to go.
  • It can be not easy to measure success. We all know product managers love analytics to prove success. Measuring success in an API is difficult.
  • Adoption of newer versions of an API, once the product is live, is also challenging.

Platform capabilities – when we operate Ignite API, we run it as a platform. We look at our API producers and features teams, and we have about 15 teams building APIs and web app features. Some guiding principles when it comes to API design –

  • Be customer-focused. Your API consumer should be at the heart of what you build.
  • To ensure we hit the product market fitters, we need the 5-5-5. An API consumer should take 5 seconds to understand your API, 5 minutes to make a first request, and five days to use your API in production.
  • Developers should see consistency. All APIs in an API suite should all look like the same person builds them. This is where you leverage things like API Standards and linting docks to help control this. Consistency enables predictability. When you get predictability, you have an easy API system to use.
  • Privacy and Security should be first-class citizens in API design. That’s the only way to safely scale your APIs and get them out into the world.

In summary, no API is an island and interconnect stability is essential, providing customer value. Customer expectations are evolving and becoming more complex. Partnerships defend market share by creating sticking customers. Customer eyeballs in your experience are not essential; product value is.

Erik Tveitnes

Erik Tveitnes

API Lead at REA Group

APIdays | Events | News | Intelligence

Attend APIdays conferences

The Worlds leading API Conferences:

Singapore, Zurich, Helsinki, Amsterdam, San Francisco, Sydney, Barcelona, London, Paris.

Get the API Landscape

The essential 1,000+ companies

Get the API Landscape
Industry Reports

Download our free reports

The State Of Api Documentation: 2017 Edition
  • State of API Documentation
  • The State of Banking APIs
  • GraphQL: all your queries answered
  • APIE Serverless Architecture