Swedish online retailer Fyndiq excited our Nordic APIs audience in November last year when co-founder and CTO Micael Widell declared one of their biggest business milestones was when they released their API. Now, Micael is working with his team of 11 developers to see how APIs can empower internal structures (via private APIs), support business integration (with partner APIs), and continue to enable an increase in market reach (via public APIs).

Private APIs at Fyndiq: Mapping processes and lessons in consistency

Key lessons:

• Starting with a private API will help you establish the right data architecture for scalable growth
• A private API helps ensure data consistency and naming conventions
• Using private APIs can quickly become an easy method to explain your business processes to anyone in the organisation

Coming from a small startup team that was all development-savvy meant that for Fyndiq (a Swedish online retailer specializing in providing a wide range of products for suburban and rural women), private APIs seemed less of a priority in their business model. As a result, Micael explains, there was not as much forethought into ensuring the right data architecture systems were in place from the start. This sort of design question might be more intuitive for a larger company, but for our November event last year, Micael urged startups and smaller businesses to take the same care with designing private APIs as if they were a large organization, as this will be necessary as your business scales.

Focusing on data systems architecture helps “optimize the performance of the API, reduces duplication, and ensures consistent data naming and structures across business systems,” Micael says.

Micael shares the data architecture mistakes Fyndiq made when starting with a partner API which they are now needing to overcome as they empower the company to use private APIs internally to manage business processes.

At our November event, Micael shared the data architecture map that came about organically as the business decided to build out backend services (like customer support), alongside providing merchant pages (where partner suppliers could view their products in the Fyndiq catalog). They also thought the time was right to create an API. Here is the data architecture they ended up building:

The problem quickly became apparent as Fyndiq tried to match the rapid scaling that the API had generated. As more merchants – with more products – came on board, discrepancies between how product data was named in the merchant pages and how it was named as an API resource became apparent, creating headaches as the system grew.

“When we built this platform, we didn’t really think it through and that has caused us a lot of problems,” Micael shares with us. “A sound architecture is one where you place an API close to the database, and then all of the merchants can communicate with the API. You don’t have to worry so much about performance, as you don’t have to abstract. It takes a lot of time to transform into that architecture when you have already started scaling with the old architecture. We solve it step by step, we are moving toward it. Every month, we make small improvements. It will be ongoing work, you can always modularize more.”

At our Nordic APIs event in November, Micael shared with us what an ideal data architecture would look like for their business model:

“Now, we are working hard on internal APIs so you reach the same resources in a unified way. That is our first step. That would then prepare us for REST APIs [internally]. For example, one of our most central resources is the product resource. Now we are trying to isolate that, so that every time you try to do something on a product, it uses the same code to validate fields, so that everything is unified. Once you have that, it is really easy to expose that to the REST API.”

With APIs now facilitating business process flow across Fyndiq’s operations, Micael is also finding another added benefit of using internal APIs: they can quickly explain to anyone within the organization how business strategy is implemented in a very practical way. Internal API usage helps clarify the business processes, relationships, and movement of data and workflow within an organization and can help anyone within the business better understand the unique operational advantage the business may have.

Partner APIs: Identify your scalability

Key lessons

• For partnership uptake, ensure your API minimises integration costs
• Partnership usage of APIs is a practical way to identify a scalable model for your business
• Using partner APIs lets your developers see good and bad practices in API design

“We use APIs with payment providers,and we also have a lot of marketing related integrations,” says Micael. “For example, if you have made an order with Fyndiq, we have an API with a ratings website to enable customers to write recommendations about their Fyndiq experience. So we have a lot of small marketing APIs integrations.”

Micael says that working with these external APIs has helped the Fyndiq developer team understand as much about designing APIs as consuming them. “In some ways, we are working so much with other companies’ APIs, we see a lot of bad patterns, and a lot of good patterns, so our developers are learning a lot from that. One of the most important things is that it is easy to use and understandable. We get inspired — and scared! — by how some people use APIs.”

While available as a public (open) API, Fyndiq’s own API was intended as a partner-like API to help their merchant suppliers better add products to the Fyndiq catalog. To the amazement of our Nordic APIs audience in November, Micael shared a graph showing the growth that Fyndiq experienced after releasing their API. This curve shows how the dramatic uptake in sales is directly correlated to API usage. This made it crystal clear that the business was benefiting greatly from the introduction of an API:
You can see all of Micael’s November presentation on our YouTube channel.

“We created the first version of the API in March in 2011. So then we released the API and started talking to merchants and platforms and started getting some integrations. Then we got a good integration with a platform, so that all the web shops that were connected to that platform were joined to our shop, so we grew a lot from that exposure.”

Fyndiq had originally presumed that its niche would be to have a specialty product range of minimal products, but linking via API to retail platforms reversed that thinking for the Fyndiq team. “That was when we realized that for our business model to work, we needed many thousands of products, and at the same time as getting these products, we figured out how to do marketing well. So 50% [of the growth] is from having lots of products that come through the API, without the API it wouldn’t have worked. And 50% is learning how to leverage things like marketing, as you scale.”

One of the secrets to Fyndiq’s API uptake, he believes, is that it is easy to use for merchants who want to share their products. “You want to minimise integration costs for the other side when you are doing business-to-business APIs,” Micael says. “It was really essential that the merchant has an easy way to put up a lot of products, so it was really important that we created an API.”

Public APIs: Dog-fooding your API

Key lessons

• Encourage internal developers to use your API
• An open API creates competitive advantage
• Open APIs will change your whole business culture

Micael stresses the benefit of beginning with private and partner APIs, and moving on to opening up capabilities with public APIs: a more robust API design. “All internal applications should use the same API as external users and customers,” Micael argues. Micael believes that if Fyndiq had started with an internal API and had enabled internal developers to consume the API in the same way as external partners (often referred to in API developer circles as “eating your own dog food”), it would be less likely to have issues like naming inconsistencies and different validation rules (where in one system a product title might allow 50 characters but in the API only allows 40 characters).

Fyndiq has been able to use their API to carve out a strong market position. He fervently believes that an open API will help a business create a competitive advantage, and that an API can help leverage a deeper level of interaction between a business and third-party developers. “But you do need to communicate the roadmap for your API continuously,” Micael encourages. This approach builds trust and develops good relationships with customers who will be more confident with integrating your API into their own business workflow.

In a final reflection, Micael has also been surprised at how the business API strategy has fundamentally shifted the workplace culture towards the “composable enterprise”. This is the idea that any of a business’ capabilities and data assets can be modularized into stand-alone components that can then be plugged into new configurations by business partners and customers. It is considered a necessary characteristic for businesses competing in today’s cloud-enabled, data-driven, mobile marketplace.

Travis Spencer discussed some of these in his talk last year on how businesses are increasingly needing to become a platform that offer multiple connection points. In my interviews with business experts around the world for ProgrammableWeb, many of the industry’s predominant thought leaders think that while this is the goal, the idea of “platformification” is often still a theoretical concept that hasn’t influenced actual business delivery.

Micael sees the use of APIs as being instrumental in helping Fyndiq make this sort of thinking a practical reality for the way they do business:
“It’s hard to put the finger on one place where we learnt this. We noticed when a lot of developers start working on the code at the same time, we realized that it would be easier [if capabilities and data was available in modular, component form]. And when you have a lot of different endpoints to the one resource, it creates a mess. So we saw that when you have a common API with common documentation, it has changed the way we think. Now we believe every feature you create has to be a module with its own API.”

Choosing a private, partner or public API strategy is an important decision for businesses seeking to leverage new computing paradigms (e.g., cloud and mobile). This is not typically an either/or decision. As with Fyndiq, any of these types of API usage should have a comprehensive approach that affects business processes, product development, service delivery, and even company culture. Participants at our Nordic APIs events in Stockholm, Copenhagen, Helsinki and Oslo will see how businesses are embarking on the API journey, and how private, partner and APIs are being used for strategic advantage in all facets of their business.

[EDITOR’S NOTE: Nordic APIs and the organizers, Dopter and Twobo, have no connection with Fyndiq and neither have received any direct or indirect compensation in exchange for this post. We’re merely fans of Fyndiq’s because they are indeed making the Nordics programmable!]