If you’ve ever integrated a software application with a third-party system like an accounting, chat, or marketing product, you likely used an API to perform the integration.

When the API is well designed and easy to use, it’s a good experience. Otherwise, the integration will go poorly.

The experience also depends on the software you’re trying to integrate. For instance, one business I worked with wanted to build its existing software into an API. However, the product was in such poor architectural shape—including critical business logic located in front-end JavaScript code, server-side logic written in an obsolete programming language, and no testing—that my team spent years trying to build an API on top of the existing code. If that system had been built to support an API, it would have been a different story.

How can you design software applications to facilitate such integrations and enable more automation for your customers? By taking an API-first approach. Let’s look at how you can use this strategy to improve both integrations and automation.

What Is API-First?

In many software applications, automation and integrations are usually hacked together. Each integration is built as a custom “one-time” application code embedded into the core codebase. These custom pieces can’t be reused, are difficult to understand, and often follow different conventions than the product code.

In an API-first approach, you design and build an API (or multiple APIs) as the foundation of further products and tools. The API also becomes a core product in its own right. Developers can more easily build extensions, integrations, and novel tools by using APIs as building blocks.

With the growth in the different types of clients that interact with a given software system—like mobile applications, third-party marketplace applications, single-page web applications, IoT, and data analytics—using an API-first approach has become a popular way to build software applications that are easy to integrate with.

As in the above example, the typical approach to APIs is to build an API on top of existing web application code. Your API then depends on that code.

An API-first approach is similar to service-oriented architecture, in which the goal is to create reusable, self-contained units of business functionality that can communicate with each other, or other systems, using network communication. This is what API-first accomplishes by applying this thinking from the outset of a software product. In other words, everything else depends on your APIs.

Use Cases with API-First

An API-first approach to designing your software has many benefits, such as enabling frontend projects to be worked on in parallel since you have a well-defined contract between the API and the functionality it exposes.

More specifically, using an API as your foundation for other software products helps you easily automate your system and integrate it into other systems.

Companies with well-designed APIs at their core include Stripe, Slack, and Twilio. Not only do their APIs power their own tools—such as desktop apps, client libraries, and web apps—but the APIs are some of the easiest for third-party developers to integrate with.

Let’s look at some use cases of how you might operate from an API-first approach.

Workflow Automation

Imagine that your software as a service (SaaS) product helps employees to schedule their time off work. If your product could be integrated into Slack, customers could schedule their time off within your application. For other products that your customers use a lot—email or chat programs, for instance—your product could integrate right into those applications.

Suppose your products could be integrated into workflow automation products like Zapier, Automate.io, or IFTTT. By using a CMS like Strapi that can generate APIs, you could build an integration for Zapier that could automate cross-publishing content to different blogs or publications.

Automated User Provisioning

When selling and working with larger enterprise customers, software products need a way to automate common tasks like user and group membership provisioning.

SCIM, the most popular standard, can help your customers automate the provisioning and management of their users. SCIM is a specification for building an API that allows your system to communicate with common identity providers like Okta, Azure Active Directory, and OneLogin.

If you’ve already taken an API-first approach, then building a SCIM API on top of your existing products could be much easier than starting a new API from scratch.

Rich Marketplace Ecosystems

If other companies can easily build integrations using your products, it helps your company gain a rich ecosystem of third-party applications in an app marketplace. If you look at all the various integrations available with Strapi, you’ll see that many well-known products can easily integrate with Strapi and enable even more automation around tasks like email and content searching and indexing.

The easier it is for your system to integrate with these apps or plugins, the more opportunity your organization has to bring value to your customers.

Ability to Easily Extend Your Product

Early in the development process, you may want to design your product with the goal of additional functionality through an API or webhooks. By leveraging your API, you or other developers can build plugins that extend your product or add extra features.

One example is this Strapi comments plugin that gives your CMS the ability to create and manage comments or report abuse. Since Strapi has built-in tools to generate APIs, this plugin also enables you to expose the comments as a public API.

By using webhooks, CMS content can be consumed by a static-site generator like Gatsby. This gives you the flexibility of a CMS to create content, but also the power and performance of publishing and representing that content as a static site.

Benefits of an API-First Approach

Let’s dig into some of the benefits of using this approach to design and build your software products.

Less Wasted Work

Have you ever worked in a codebase where you had to keep asking other developers, “Hey, is there any way to do X in this system?” Likely the answer was some obscure function located in a random place, or there was a third-party library to do X, or else nobody knew.

When you take an API-first approach, you expose all of the available business logic that is reusable through API contracts and API documentation. Using something like OpenAPI can help with API discoverability and make it much easier for other developers to see what logic is available for reuse.

Use Open Standard

Using an open standard like OpenAPI gives you a standardized way to describe what your APIs can do and how they can be used. This can significantly help with automation. Many tools just need to read your OpenAPI documentation to produce client SDKs and integrations.

Work in Parallel

If you establish a solid contract between an API and its clients, these products can be worked on in parallel by using tools like mock servers and mock APIs. While a team builds the API, other teams can simultaneously build a desktop app, mobile app, and web application.

Reuse Content

If you are using a headless CMS like Strapi, you can connect that content to various representations of the same content: static web pages, data/content analytics, desktop or mobile apps, and embedded content. This means you can write your content in one place and reuse it everywhere else. You can also integrate with a search API like Algolia.

Conclusion

Taking an API-first approach to designing and building your software can help you create products that are easy to integrate with others and provide good business value for your customers. For example, your large enterprise customers benefit from SCIM user provisioning and your internal teams gain solid API contracts that enable simultaneous workflows.

If you use a CMS like Strapi, your application’s content can be reused to power static web pages, analytics, and search capabilities. Strapi gives you powerful tools like:

• An admin panel where you can manage your content

• The ability to automate and expose a custom-built API for the content you’ve created

• Webhooks that can perform tasks like trigger builds of connected static web pages

If you’re looking to use an API-first approach to ease the development of integrations, then Strapi might be the way to go.