Search Engine Aids SDK Discoverability

Automatic SDK generator APImatic has released a free SDK search engine site, The move seeks to address a key problem emerging across the API economy: how to ensure that APIs and SDKs are discoverable among the developer consumers who need them the most. APImatic’s solution is to build out a user-friendly Library-like interface that lets users search for the SDKs the service is constantly generating.

Co-founder and CEO Adeel Ali says the search feature used to be a part of the main APImatic site, but that “whenever we used to show that you could search SDKs, developers would go, ‘Wow, you have a Google search for SDKs!’ So we thought, why not separate it out as it has a different audience? So we did that.”

To create the SDK search engine site, APImatic crawls GitHub and other public repositories to identify publicly available API descriptions in either APImatic’s description format or from the Internet in one of the following formats:

APImatic then auto-generates SDKs for the newly discovered APIs and adds them to the search engine database. “We literally hacked GitHub and went to all their public repositories, and where we found a good-quality API, we pulled it in,” says Ali.

A Library of Auto-Generated SDKs, Not All SDKs

By spinning up their own SDKs for public APIs, APImatic and could be confusing some developers who then use the SDK and seek help directly from the API provider. For example, one of the APIs shown in the directory is online car retailer Edmunds:

But Edmunds has also released its own SDKs, so there is the potential for confusion when developers use the APImatic version but ask the Edmunds developer team directly for help solving coding problems.

In truth, this risk is small given the benefits of to API providers overall. For starters, as Will Flaherty from SeatGeek noted when APImatic was first released, any potential channel that brings new developers to their APIs is welcome, even if that means there are two SDKs publicly available.

Also, API consumer developers are used to having multiple tools available. In fact, the most successful API providers encourage and promote API consumer developer-generated wrappers and other tools. They may not be able to support or respond to queries about those third-party-created tools, but they recognize that their existence is part of being a growing ecosystem that is now leveraging network effect benefits directly between ecosystem actors, without the API provider needing to be the one always driving API uptake.

Ali is hopeful the next stage of will incorporate a developer marketplace Platform model, where developers can fork versions of the APImatic SDKs and modify them to be fit for purpose. Ali explains:

We want to make it a channel for developers and see how much time and effort they can save with SDKs. If that is possible then we might not even charge developers for using it, but we could create a marketplace where developers can charge.

We hope developers can modify these SDKs via APImatic, redefine them, modify them or make the SDK the way they want. Developers like to have total control over their settings. Then, potentially, developers could sell that version of the SDK on the platform. We don’t have any opportunities for that at the moment, but we are thinking about it. For example, a developer could create a lean version of the SDK with just a few endpoints.

For now, one of the greatest strengths Ali sees in developers using APImatic’s SDK versions available on is that for mobile development, using these SDKs can create a more uniform design:

We get lots of requests for SDKs that can help create consistent apps across all mobile platforms. So if a company wants to build apps for a complete mobility Stack, the look and feel should be the same. Normally, an API provider would have separate teams that build each SDK so the end SDK products would not be consistent. But having consistent SDKs with the same endpoints for each mobile application is very important, so we are targeting that market now.

API Middleware Industry Maturity

The creation of the standalone service also points to two trends seen in the API economy in recent weeks. Like AnyPresence’s JustAPIs product launch this week, the site shows how API businesses are identifying standalone products that may exist within their business’ overall service suite. This is being driven in part by a predominant industry culture that privileges composability and microservices design, and is in part an artifact of API leaders’ experiences in business pivots, where they understand the need to be laser-focused on the core functionality of each product.

Alongside this, the launch of reflects a wider trend of the maturing API middleware industry: In the past four to six weeks, Microsoft, WaveMaker and Dell have all released new products aimed at speeding up app and API development and deployment, while API tools services like SmartBear and Runscope have released new products and features.

Be sure to read the next SDK article: ProfitBricks Releases Ruby SDK for REST API