We tend to think of API as an end-goal when most of the time it’s only a tool serving a product or business purpose.

Most of the time when we talk about API, the discussion revolves around REST vs GraphQL, versioning, pagination, depreciation, client SDK, authentication or documentation — which are all great topics but that usually misses some highly important aspects.

From API to API Integration

Private and public API don’t mean much these days, let’s distinguish them from the point of view of the consumer and call them internal and accessible instead.

While building an internal API is a technical choice, providing an accessible API is not. This decision is a product & business one. At some point you want (need), customers or partners to integrate with you. Integration is about easing access to your product and/or teleporting part of it to enrich your partner’s one.

What matters with accessible API is how those people, that you don’t control, are going to use it, that’s what we call API Integration.

API Integration is much more than just API

The initial API design discussion is still important (maybe they shouldn’t if we standardized API…), but it’s now only a subset of the overall API Integration discussion.

API Integration is about product and feature, about UI/UX, engineering, but also about Ops (scaling, rate limiting, securing, logging etc.) and in the end maintenance. That’s a whole lot more than just the usual:

“Hey I’m just going to consume this REST endpoint”.

All those layers represent many responsibilities, requires coordination, time which make them costly. As the API provider, that friction is a challenge that needs to be overcome to make sure to be integrated. But being integrated is not enough. Integrations needs to be good enough to make sure it reflects the value of the product, but you still don’t really control it.

What’s next?

What if we could have a tool that eases the cost and friction of integrating and at the same time improve the control over integration?

Stay tuned ;)