Do you have a product and want external developers to integrate with it? Deciding whether to build APIs, low-code, or no-code integration products can be tough. This article offers a strategy for deciding and ensuring developers integrating with your product can effectively meet their technology and business goals.

Defining your ideal developer profile

Based on the principles of customer obsession, start first by understanding your product's target customer segments and, via it, the target developer profile. It's surprising how many companies miss this and assume all developers have similar needs. A good framework asks the following questions.

1. Question: What customer segments is your product targeting? Are these large enterprise companies, SMBs, or high-growth startups?

   Motivation: Large enterprises have integration teams specializing in iPaaS platforms such as Mulesoft Anypoint, Workato, Boomi, etc. Such teams typically only develop integrations using the selected platform. However, teams at smaller companies prefer using the same programming language and frameworks as their primary product. Further, sometimes, the integration developer might not be a developer. For example, someone in the sales or marketing team wants to use a no-code option to quickly launch a proof of concept.

2. Question: Is your product meant to be deeply integrated with the external product, making both indistinguishable or will it be cleanly separate?

   Motivation: Heavily integrated experiences, like, for example, ones that are based on the workflow and resource lifecycles of external products, often are composed of more granular coordinated API use with custom domain logic. Single-shot or "silo-ed" integration use cases represent the lightly integrated use cases. For example, Instacart uses Stripe APIs to build a rich and flexible experience for order fulfillment - from order placement to cancelations and returns. On the other hand, OpenAI uses Stripe Link to power its one-off checkout process. Further, Gusto Embedded Payroll uses a white-labeled "full solution in a box" embedded approach.

3. Question: Does your target audience understand your product's domain well, or is it in a niche domain?

   Motivation: Products like authentication or email delivery use well-understood industry concepts and need less education for integration development. On the other hand, products in niche verticals such as background checks, like Checkr, are less intuitively understood. Your product's conceptual learning curve is important, as all integration developers will go through it. Typically, the higher the learning curve, the more effort and help are required, making low-code integrations more appealing.

4. Question: How much of the external product can your integration access, and how much control do you want or have over your customer's end-user journey?

   Motivation: Some external products do not allow widget-based integrations on their user interfaces. Further, products like Uber's mobile app don't even use third-party SDKs. In certain cases, such as when dealing with credit card details or legal agreements that require compliance, it may be necessary to prevent the external product from having any control. Knowing the holistic user journey and the product boundaries (customers vs yours) will help you craft the most effective integration solution.

5. Question: How often are your customers willing to accommodate breaking changes in your product (in your API or otherwise)? And when that happens who will implement the upgrade?

   Motivation: Once a company integrates with you, it's generally hard for them to keep the integration updated based on your product's cadence. Knowing your product cadence will help you propose an integration evolution strategy — whether it's via APIs, low-code, or no-code. It's up to you to present these options to your customers, and eventually for them to make trade-offs. A strategy is outlined later in this article.

Defining your success criteria

With the target developer profile identified, the next step is to define what success looks like for them. This spans not just the selected integration option but the entire developer experience. I will be discussing developer experience in a future article. Companies define success metrics in various ways. Some examples are:

1. Time to go live.

2. Time to make the first transaction in your product via the integration.

3. Number of your product's features adopted.

4. Number of customers using the latest version of the integration option, like the API or SDK versions.

5. Number of support requests.

6. Number of SDK downloads.

7. Developer CSAT scores.

It is important to define this based on your business goals, especially since some of them might be mutually exclusive at first, thus involving making tradeoffs.

The current state of the industry

The following table represents commonly seen integration options.

APIs

APIs are the most granular and popular way for your customers to integrate with your product. Adopting a popular standard such as JSON API described via Open API and versioned via SemVer or CalVer can make for a productive developer experience. Further, you can leverage products in this ecosystem, like Open API based documentation site generators like Redocly to bootstrap a good developer experience.

When your customer developers adopt this

• They have the most flexibility to integrate with your product.

• They will have to invest in upgrades based on your product's cadence. This makes it important to think about API versioning upfront, even if it's just a placeholder at first, so an API governance program can guide upgrades in the future.

An API-first strategy is fundamental to enable all other integration options. Following are some guiding principles towards it.

1. Focus on using the OpenAPI specification as the source of truth. All integration options, SDKs, and documentation generators are based on it. For productivity, you may generate this spec in various ways, like via Smithy or TSOA.

2. When building your frontends, prefer developing them on public APIs instead of private ones. This will make those features available to your customers, too. Jeff Bezo's API manifesto is this taken to another level.

SDKs

The natural extension for developers using APIs is to seek SDKs. An SDK can make developers more productive with APIs via programming language constructs such as Object-Oriented Programming, static typing, etc., and utilities to perform common API operations like webhook verification. Often, SDKs correspond one-to-one to underlying API operations and work at the same level of conceptual abstraction. Therefore, investing in SDK development doesn't always make sense. APIs can go a long way, and SDKs, if not developed correctly, can be a development burden on you with limited impact. SDKs often lag from APIs due to the additional work. One technique to determine which programming language SDK to target is to look at the User Agent header in API calls.

OpenAPI-based SDK generation does require non-rival effort to work properly. Plaid's OpenAPI-based SDK generation strategy outlines some of the work more deeply. Stripe uses a more custom and integrated strategy here. Products like Stainless aim to address these gaps. Further, programming language-specific ones like Kubb in Typescript use OpenAPI specs for SDK generation, API request validation, test stub generation, and more, making for a compelling vision.

When starting on SDKs, note that high-performance products prefer using APIs over external SDKs to better manage their product size and dependencies. Uber's mobile app is a good example of this.

Embeds

Embeds are web or mobile components your customers can use to embed your product experiences in their product pages. Stripe Elements and Checkr Embeds are good examples of this. PayPal components are another popular example built using the kraken/zoid library. This option is commonly seen in products that capture sensitive data such as credit card information or social security numbers. The primary benefit of this option over hosted pages is that your customer's users don't have to leave your customer's product in their user journey. The primary hindrance in Embeds adoption is customers resisting access to their custom frontend user experiences.

Developers using this option would

• Use your embeds in their product pages. It will require some code, though it should be small.

• Most embeds have good theming capabilities.

Like hosted pages, these are evergreen integrations. Embeds can target both web and mobile platforms. In the early days, an iframe-based approach can work for both platforms. When you find customers who truly want a native experience, you may evaluate building React Native or Flutter SDKs. The Stripe React Native SDK is a good example of this.

Hosted pages

These fully hosted and pre-built solutions allow limited flexibility, such as theming, custom domains, and configuration. Popular examples are Stripe Checkout and Auth0 Universal Login.

Developers using this option would

• Typically, write the least amount of code, if any. This makes it quicker to test and launch.

• Perhaps still listen for webhooks to drive real-time product features, such as product notifications.

This evergreen integration option requires no upgrades and always includes the latest features from your product. Often, no developers are required, making this an ideal solution when your ideal developer profile resembles non-technical teams such as sales and marketing.

One commonly seen adoption pattern is that customers first adopt an easy-to-go-live option like hosted pages or embeds to evaluate your product and, upon business success, double down with a deeper, richer integration via APIs.

This option doesn't work when

• The external company wants full control over the user experience

• Customers want their users to stay within their product.

• Wants all third-party providers, such as your product, to work in the same consistent way.

Unifying APIs and library products

This category deserves a special mention. Products like Merge and Finch in the HR space promise customers one API to work across multiple HR systems. Hyperswitch does the same for payment systems. Similarly, libraries such activemerchant/active_merchant provide a unified way to work across multiple payment gateways. If your product is a service that can plugged into such products, then it's worth investigating whenever you see customer demand. Often, customers make nuanced tradeoffs between using unifying integration products and integrating directly to leverage a product's unique features. This is something to be careful about.