Guest contribution covering an impressive automotive API journey. Follow the rise of the niche Car Registration API; from market pivot, to price-adjusting, to scaling sales internationally.

It’s unusual for an API to become the main income stream for a company. Often an API is developed as an afterthought, typically for one of two main reasons;

• To help facilitate sales of products and services from third party affiliates or resellers by making it more easy for them to access product or service data, or remotely manage the services you provide.
• To foster an ecosystem of value added services by third parties – to augment your offerings and deliver more value to end customers.

In both cases the product or service is pre-existing, and the API ‘opens up’ the data pertaining to those offerings to third parties to encourage more indirect sales.

But, in rare cases, an API can take on a life of its own, effectively making the underlying service so much more appealing to the right people that it becomes far more valuable than the original service. This is the backstory of one such API.

Day zero.

In 2015, while booking a routine vehicle test, a small but interesting feature appeared on a website’s booking form. On entering a car’s license plate, the car’s details would appear on the following page. This would have been of little interest to most users of the website, but to us, it was the genesis of a very successful API business.

At the time, mobile apps seemed to be the answer to everything. Developers were getting rich from “Flappy bird” and “iFart” and it seemed that with minimal effort anybody could make a fortune from the app store. So, we developed an app that allowed people to enter car registration numbers in the UK, and view the car details once they were retrieved from the DVLA or DVLNI (government agencies in the UK that manage this data).

The app was a dismal failure. It was of so little use for a personal car buyer that only a handful of people purchased it. Many were disappointed, and the sales collapsed. The only regular users were a handful of garages and car sellers that dealt with many different vehicles on a regular basis.

It became apparent then, that the market for this service, was not B2C, but B2B. Only businesses that dealt with hundreds or thousands of vehicles would need such a service. The option then was to either pick a specific vertical, and develop software for that specific type of business, or develop an API that would be further integrated by third parties into software that satisfied the requirements of those verticals – the latter option was chosen.

The mobile itself ran off an API, albeit a private one. In order to make it public, it needed to have an authentication mechanism, a credit system, documentation, and code examples. It also needed a developer portal to advertise it’s availability. Initially, there wasn’t even a payment system; it was handled manually by updating credits in a database.

Selecting the pricing model.

After the API was created, it was listed on a few websites, most notably ProgrammableWeb, and a few choice answers on StackOverflow. This delivered virtually all the visitors needed to get started. It got off to a slow start, with only one or two businesses taking it on board, and it became clear that the pricing model was wrong. Almost every potential client complained about the price, and the take up was too slow.

So, the pricing was dropped, and the number of customers increased dramatically. Pricing an API is a difficult task, since often the underlying cost is very low. However, it’s not wise in business to price yourself just above cost price. Unless competition is extremely high, and you are selling a commodity, it is best to price at a level which is just under the level at which the customer would cease to make a meaningful profit on the up-sale.

Imagine your were supplying silicon to Intel. You wouldn’t price your product just above the price of sand, rather, at a level below the resale price of Intel computer processors.

Many APIs, such as social network APIs, are offered for free since they assist in the sale of a product or service provided by the API developer. However, business processing API services must be priced according to the value they deliver to consumers.

With the price point adjusted accordingly, and a volume discount structure to encourage the bigger fish, the API started to take off, in the UK at least. Various companies started using it and payments started to come in.

But like with everything on the Internet, the cost of exporting is close to zero, and the market opportunities are massive. The opportunity cost of not looking outside your own national borders is enormous.

Scaling up.

So, the next step was to look abroad to see what other governments offered car registration data available to the public through an open data initiative. We discovered that the Nordic countries (Finland, Sweden, Norway, and Denmark) offered this data quite readily, and through a certain level of bureaucracy it was possible to expand the API in one fell swoop to cover millions of new potential customers.

With the added data came the required localization, which in practice meant both translation and support for multiple currencies, like NOK, SEK, DKK, and EUR. For geographical targeting, multiple landing pages were made for each specific country (see Finland, Denmark, Norway, Sweden). This turned out to be a big marketing win, giving both an SEO boost, and focusing the message much more on the individual customer, greatly streamlining the onboarding process.

Another quick win included automating the payment process so that people could pay without having to exchange emails first. A freemium account was a great benefit; the small cost of offering a little access for free was greatly outweighed by the increased trust and quicker onboarding process.

Offering a free trial proved to be very important as a marketing strategy, especially since people from various job roles are often involved in the API validation process. The API tester tended to be a developer, who, although technically capable, had no means nor desire to pay. However, the tester needed to give the all clear before the manager would take out the company credit card.

Providing reporting tools, such as graphs, downloadable reports, and low balance warnings all helped keep existing customers happy, and reduced the day-to-day workload of answering questions for customers that could be handled via self-service. Although these tools do not lead to new customers, they do maintain recurring sales and reduce labor costs.

Once an established customer base began to use the API regularly, it became increasingly clear that the most important issue was reliability. Any outage in the API resulted in lost customers for them, and in extreme cases, a website failure. Therefore, resources were employed in setting up routine tests to ensure the API was constantly operational.

These tests were effectively a simple executable set as a scheduled task on the server that ran every night, and emailed developers the result of all the tests. More basic tests were run every hour, ensuring that serious breakdowns could be spotted in an hour, and less serious issues could be spotted within a day. The increased reliability led to much higher customer satisfaction and increases in their usage levels.

As the business expanded to further countries, specifically the USA, load on the API and on the server became a significant issue, as a single dedicated server began to degrade in performance as the hits to the API increased. Normally, at this point most developers would recommend cloud computing solutions, however, since the load was gradually increasing, rather than spiking, it was possible to gradually offload certain ancillary functions away from the main server, and to secondary, cheaper servers.

Final words of advice.

Many API developers get caught up on the implementation of the API, the JSON format, the technology stack, and scalability before the first customer has ever even tried it. Most developers can handle whatever you throw at them, be it XML, JSON, or YAML – and the odd quirks are quickly forgiven. Security is a big concern, so hosting on HTTPS is a must, and offering a per-IP lockdown is really useful. But, the most important thing is that these features can be added as they are asked for, and not necessarily front loaded as a prerequisite for launch.

Versioning was not something that was considered in the initial design of the API, so as new data becomes available, or a more intelligent way to represent data becomes apparent, it’s not so easy to change. An active API may have hundreds of client applications developed by your customers that depend upon a fixed formal structure of your API’s response format. A tiny change, perhaps insignificant to you, may break a customer’s application. More established APIs, like Facebook, Twitter, Stripe etc, use a version number in the URL, to manage this and a very public sunsetting period for old versions.

This particular API was developed using C# .NET on a Windows server with an SQL server database. Over months, the code was gradually refactored and tidied into modular and logical structure. This facilitates easier and faster maintenance, leading to less downtime. However, refactoring is normally the lowest priority of all tasks.

As the business stands as of the time of writing, the Car Registration API is being used by over 3,000 customers worldwide, handling over 3 million queries, and has had interest from the likes of Uber, Tesla, IBM, Bosch and many more.