By
·
4 minute read
With the Woven Market Map, we undertook a study into the advice industry's APIs and other integration methodologies that exist today.
Our summary? Advice tech APIs are significantly lagging behind other industries. But if you’re reading this article, you are probably already aware of the problem .
Starting with API accessibility, we look at 75 advice tech providers and rate their API capability with a traffic light system. In effort to increase understanding, awareness and expectations around APIs, we thought we'd share our findings with you.
Lets start with our ratings:
- 18% Green - We approve
- 17% Amber - Points for effort - but not there yet
- 65% Red - Not started or too much secrecy
The Woven API access categorisation
The Woven API access categorization
Green (some or all of the following):
- There is a clear, documented API offering
- API is RESTful with JSON payloads
- API documentation is publicly accessible without human intervention
- A sandbox environment or test data set is available to try out the API
- Documentation is easy to understand and use
- API resources like Postman collections are provided
- It's possible to start building an integration without incurring costs
- API access is granted through terms and conditions rather than specific agreements or NDAs
Amber:
- An API exists but requires human intervention for access
- An API exists but no clear guidance on getting started is available publicly
- API exists but uses SOAP/XML instead of REST/JSON
- Data export capability exists but is limited to CSV format
Red:
- No evidence of API access for 3rd party integrations
- No ability to export client data programmatically
2/3's of Advice technology providers don’t have an integration or data portability mechanism for 3rd parties to build integrations to.
It's scary to say 2 thirds of the industry haven’t invested in data portability. But that’s not to say many aren’t going to. There might be a number of reasons a company is flagging as a red but in fact falls into one of the categories below:
- The company is a start-up.
APIs require a stable product and data schema to support. Without a confident or mature product, it is sometimes not feasible for a company to develop a public API. In these instances, a start-up would take it upon themselves to build integrations from their side against other products with an API. - No business case to provide data to other systems.
In some instances a software might be at the end of or a user journey, or an isolated standalone island. In this instance, there might be no desire from users to integrate.
Red flags for the Red lights.
Here are some red flags in our analysis that we want to call out to our readers:
Business requires an NDA to access API docs.
Your API documents are not the secret sauce to your system. There is no benefit for an NDA in the integration process other than slowing down innovation and creating friction in collaboration. If required, create a lightweight API agreement. But ideally, provide an opt-in via terms and conditions. You don't want to sink down on a 3rd party's backlog, when they were eager to do the work in the first place!!
Business has no mention of APIs or data portability on their website.
The modern selector of technology is highly cognisant of APIs and usually has a requirement for data portability. By not referencing your firm’s capability on your website, you’re losing business from potential customers and suppliers who are looking to integrate with your product. You could be missing a valuable income stream.
Bad documents...
Lead to bad integrations and costly support. What is an API without documentation, and if the documentation is going to be poor, the proposition will create a world of pain for both parties and likely end in reputational damage.
Assessing charges for API usage
Naturally, charges for APIs are not particularly loved in the industry. Let’s dig into why a provider might charge for API usage.
An API, is costly to build and maintain (particularly for older systems). Depending on the architecture of the API build, the costs could scale with depth or breadth of access provided. Therefore, it isn’t uncommon for providers to charge for access to 3rd party providers. In saying this, most of the industry should be considering the benefit of having integrations to and from their system as a business case, which would usually rule out charges. If every tech provider created an API and charged for it, there would be a lot of unintegrated systems around and even less efficiency than there is now.
Some providers will charge based on customer acquisition rather than API usage. That means if a customer discovers you through their “app store” they are entitled to a % of revenue (usually for a specific amount of time). This charge represents the cost of acquisition that the 3rd party has been saved by direct distribution through their store. This charging structure shouldn't be confused with API charges.
Overall, it is encouraged for a business to not charge directly for access to APIs. It should be viewed as a feature of your product and charges should be absorbed in the product's. A provider where their API is a new feature, could see this as a cost of remaining relevant. Or if it is indeed an upsell opportunity, having transparent tiered pricing strategy is encouraged.
There are many benefits from increased 3rd party integrations and extensibility in particular with customer retention where a customer can "extend" their functionality rather than look to replace the product completely. It is therefore concerning when a provider feels the need to explicitly charge a client for access to their own data.
A case for the oldies
To close out this analysis, we want to shed light on technical debt, and the cost of integrations for incumbents. An integration, like any other area of the system can suffer from changes over decades. Given an API can be impacted by the smallest of system change, many providers are conservative with the access they provide.
When an API is built much later than a product, perhaps because the system was built before RESTful APIs became the industry standard, the effort to create the new API is high. In the case where the integration is old and no longer desirable, not only are changes costly, but integrations might be so embedded for customers that, subsequent change control becomes too complicated.
We could feel sorry for these situations - but we prefer to consider the position they are in as market leaders. They have an opportunity to lead from the front. Being established with market share, the incumbents could leave behind competition with a quality API. If only they can find a way to manage it alongside their existing tech and product priorities...