This post is part of the “Tech Ecosystem Maturity” series, exploring the 30+ criteria of Crossbeam’s Tech Ecosystem Maturity Diagnostic. The diagnostic helps you understand how your partner program stacks up against others in the B2B SaaS industry, what you’re doing well, and how you can advance to the next level of maturity. To learn more and take the tech ecosystem maturity diagnostic, click here. Read the rest of the Tech Ecosystem Maturity series here.

—

Your application programming interface (API) is key to scaling your tech ecosystem. Without it, you’re putting restraints on your product, your customers, and the success of your company.

By offering a public API, your customers get more power over how they use your product and can get more value from your product as part of their greater tech stacks. The more ways your customers can use your product, the “stickier” your product will become. For instance: In January of 2022, HubSpot announced that its ecosystem surpassed 1,000 integrations — more than doubling in size in less than two years. This growth wouldn’t be possible without HubSpot’s API.

Image courtesy of HubSpot.

The state of your API, including your API documentation and your sandbox environment, directly contributes to your tech ecosystem maturity. 

Keep in mind: the state of your API is just one of 30+ criteria contributing to tech ecosystem maturity. There are multiple factors at play. To identify areas of improvement for your partner program, take the tech ecosystem maturity diagnostic and learn how to level up each criteria through actionable next steps. 

We interviewed hundreds people in the industry, and this is what we learned: 

In this article, we explore tech ecosystem maturity through the lens of your API. 

“Explorers”, by nature, are working with the resources they have and paving the best path forward. “Explorers” do not have private or public APIs (We’ll get to each of these in just a little bit!). 

Start developing your REST API. Typically, tech companies develop a REST API (The alternative and less common version is known as “SOAP”). For the remainder of this article, we’ll refer to your REST API simply as “your API”. 

To note: You may hear partnership professionals or developers use the term API in the plural form. (e.g. “We’re making sure our APIs function as expected for specific use cases.”) In most cases, they’re referring to your API’s “endpoints”. An API comprises numerous endpoints, which your developers can create, update, and remove in order to adapt the functionality of your API for various use cases (and partners).

To get started with the development process, you may need to select members of your engineering team to develop your API or hire new team members to handle the responsibility of building and managing your API. You should also hire or choose an existing team member to fill the shoes of an “Ecosystem Product Manager” (Ecosystem PM). The Ecosystem PM will be responsible for interfacing between the partnerships, product, and engineering teams to ensure your API satisfies high-demand use cases and to oversee your team’s progress.

Or, you can use tools like Stoplight.io, Swagger.io, and Redocly to develop and/or manage your API.

Once you’ve developed your API, consider releasing a beta version, like Notion did in May of 2021.

Use cases for Notion’s beta API includes: 

Understand your API infrastructure. Your “API infrastructure” includes the tech stack and supportive resources that enable your API to serve its purpose of growing your tech ecosystem. This infrastructure includes the code, the hosting, the documentation, sandbox environments (We’ll get to these soon!), and tools. Your Ecosystem PM should determine the answers to the following questions:

Give yourself enough time to test your API with new partner types and new use cases. Even if your API seems like it will satisfy a particular integration functionality, you might encounter roadblocks during the development process (like we did when we launched our tech ecosystem). You may not know exactly how your tech partners plan to utilize your API — and you may need to make adjustments to your API’s endpoints late in the game to ensure certain use cases work as planned.

“When I move a contact record from SAP to Sugar, that has to be 100%,” says Tom Williams, Vice President of Strategic Alliances at SugarCRM. “When you pick up the phone, you get a dial tone. When you transfer a record, it’s got to be 100%. So, those APIs have to be battle tested at scale and fail-proof every time.”

Work with the resources you already have to lay the foundation for your tech ecosystem. If you don’t have an API yet, start by building integrations for your most strategic partners using their APIs. Then, use early metrics of success to get more buy-in and resources for your product’s API development.

For those strategic partners, start by developing inbound integrations, which require a user of your product to call your partner’s API in order to bring specific data into your product. Once you have an available API, you can also develop outbound and bidirectional integrations so your customers can use your data and your partner’s data any way they wish.

“We seek out companies that have an API already,” says Eric Melchor, Partnership Ambassador at Bonjoro. “We’ll do the main work of building the integration.” 

And now, Bonjoro currently has more than 120 tech partners! 

As a “Producer,” it’s likely you only have a private (or “closed”) API without any public documentation. With private APIs, only customers or partners your company has invited can call the API. Private APIs often require approval of credentials and sometimes payment.

As an example, a tech company might provide a private API so that its customers can retrieve specific data from its software through a private API key — without needing to log into the software. With partners, a private API may be used for high-priority integrations. By nature of a private API, your company is limiting the amount of people who have access to your API. 

To truly scale your tech ecosystem to “Supernode” status, you’ll need to provide a public API to enable external developers to build on your platform. (Read on to learn about an exception.)

Develop a public (or “open”) API. A public API enables external developers to build on your platform with little to no involvement from your team. This is how companies like Salesforce have grown their ecosystems to include more than 3,000 partners. According to the 2022 State of the Partner Ecosystem Report, Salesforce is the most popular customer relationship management (CRM) tool, in large part due to its ability to communicate with tools in its users’ tech stacks. 

Source: State of the Partner Ecosystem 2022 Report

Alternatively, without a public API, existing and potential users may not be able to use your product in all the ways they’d like and with the tools they use most often. This could have a negative impact on your churn rates and sales as companies gravitate towards competing products with more tech stack compatibility. 

An excerpt from the announcement of Notion’s public beta API: 

“Despite Notion’s many competitive advantages, its absent API deterred many potential users.”

An (exciting) exception: Another category of APIs is emerging that exists between the “public” and “private” API categories. Some tech companies develop private APIs for internal use only, public APIs available to everyone (or mostly everyone), and — wait for it — a “partner API” available to only partners. The Crossbeam API is a “partner API”.

Publish API documentation. API documentation will help external developers understand how to build integrations on top of your API. Your documentation can describe which API endpoints satisfy particular use cases, coding instructions and tutorials, and more. Just as you can use aforementioned tools like Stoplight.io, Swagger.io, and Redocly to develop your API, you can also use them to generate API documentation. 

A few examples of API documentation: 

Image courtesy of Zuora

REST API reference for Zuora Commerce apps

API documentation on Salesforce.com. Image courtesy of Salesforce.

API documentation on Litmus. Image courtesy of Litmus.

Image courtesy of Litmus

As a “Connector,” you likely provide an open API with self-service access and public documentation. Anyone on the internet can build on top of your platform, making it possible for your product to fulfill countless use cases for your customers and prospects. The ease at which others can build on your platform positively contributes to your revenue and retention rates. 

Adopt and roll out your iPaaS solution or universal integration framework provider. Tools like these can help you develop integrations at scale while freeing up time for your internal development team. They provide the building blocks for helping your internal or external developers build integrations quickly through connections, recipes, and templates and by replicating development processes for integrations in the same category. After adopting an iPaaS solution, Typeform went from 30 integrations to 100+ in just one year.

Hire roles dedicated to your integrations. Your integration roadmap should be a priority, which means you’ll need to increase headcount to ensure your team can launch your integrations in a timely manner. In some cases, you’ll want to be first-to-market with particular integrations that complement your top partners’ latest product releases. Potential new hires could include: “Integrations Engineer”, “Senior Product Manager, Integrations”, “Technical Integrations Manager”, and even roles specific to integration use cases, like “Integrations Engineer, Publisher Integrations”.

Provide a fully-featured sandbox environment to enable partners and external developers to test integrations before releasing them. As your customers use your product in new, individualized ways, providing a sandbox will ensure your product and integrations will meet their needs without causing things to break and negatively impacting your customers.

Image courtesy of SugarCRM

Adapt your API endpoints for specific use cases and categories. As your tech ecosystem expands and your partner count grows, your use cases and partner types will expand, too. You’ll need to continue developing your API to keep up with new functionalities and ways your customers are using your product.

Contentsquare’s API and integration use cases. Image courtesy of Contentsquare.

RingCentral’s API and integration use cases. Image courtesy of RingCentral.

You’ve made it to “Supernode” status, or the highest level of tech ecosystem maturity. In addition to providing a public API and API documentation, you also provide a fully-featured sandbox environment for external developers and have adopted a no-code iPaaS solution. 

As a result, more developers can build on your platform, and your product has become an integral part of your customers’ tech stacks. In fact, your company has undeniable influence in the ecosystem as more tech companies choose to partner with you. Feels good, doesn’t it? 

—

Speaking of Supernode status, the waitlist for Crossbeam’s Supernode 2023 conference is open 👇

Ready for Supernode 2023?

Join us at Supernode 2023