One of the most common questions we hear is, "Should I charge for my API or integrations?"
It's a complicated question to answer. Every software product is different. So is every user. We talk a lot about prioritizing, designing, and building integrations. We rarely talk about where fit into your business model.
In this post, we'll walk through how to decide whether to charge for APIs or integrations. We don't intend to provide a direct answer. We intend to give you the tools to answer for yourself.
But, first, we want to get clear about the differences between an API and an integration. If you are already comfortable with this, you can skip to the next section.
APIs Versus Integrations
APIs and integrations are the two fundamental building blocks for creating cross-product experiences.
They relate, but they are not the same thing. This is a common misunderstanding. You cannot interchange the terms “API” and “integration”.
In this section, we’ll provide some definitions for both to help clarify why that is.
What is an API?
Instead of trying to reinvent the wheel, let’s start with a definition from Amazon Web Services (AWS):
APIs are mechanisms that enable two software components to communicate with each other using a set of definitions and protocols. For example, the weather bureau’s software system contains daily weather data. The weather app on your phone “talks” to this system via APIs and shows you daily weather updates on your phone.
The way you make one software product interact with the outside world is to pass data into it or get data out of it. In our case, one of those products is what your team is building. An API is the doorway that lets you do this using code.
APIs come in many forms, as outlined in the above linked article. In B2B SaaS, REST APIs are by far the most common, but only as a matter of practice. GraphQL, RPC, and other API types definitely have their place for certain use cases.
This isn’t a technical post, so we don’t need to get into the weeds on why each type is different or how to build one. APIs are a prerequisite for integrations, which the next section defines. That is important to understand.
Note: It is technically possible to build an integration without an API. It requires a more technical, “under the hood” approach. This is sometimes the best way to provide integration.
What is an integration?
APIs are the doors for putting data into or getting data out of a software product. They allow this to happen using code so that other software products can put or get the data.
As defined in the above linked AWS post:
API integrations are software components that automatically update data between clients and servers. Some examples of API integrations are when automatic data sync to the cloud from your phone image gallery, or the time and date automatically sync on your laptop when you travel to another time zone. Enterprises can also use them to efficiently automate many system functions.
Integrations are the code that does the work of moving data between two or more APIs. Integrations make two software products create a unified experience for the user. Usually that experience is to help the user automate a business process.
(This is what we call a cross-product experience.)
Integrations are more than just the mechanics of moving the data. They also include user experiences for finding, enabling, and maintaining the integration. These experiences could be very simple or very complex, depending on the needs of the user.
Integrations are critical to executing a successful technology partnership (especially Software-as-a-Service, SaaS companies). Integration is the only way to create value-additive cross-product experiences for users.
How APIs and Integrations Work Together
Imagine you have two houses on either side of a river. Both houses have a door, so you can walk into or out of them. But, without a bridge over the river, you couldn’t pass from one house to the other. APIs are the doors. The integration is the bridge.
Your goal is to make two software products exchange data so they seem as one to end users. To do so, you must have these doors (APIs) and these bridges (integrations).
Ownership of the two can differ, however.
Your APIs must be part of your product. They are fundamental. Imagine building a house, but then building a separate door that isn’t connected to the house in any way. Does that door help you enter or exit the house?
Integrations don’t have to be an internal part of your product, and they often aren’t. Middleware products like integration platform-as-a-service (iPaaS) provide the bridges “as a service”. These are third-party products that you license.
Embedded iPaaS products allow you to use that vendor to provide bridges yourself. They are still licensed products meant to "white label" inside of your product.
Or, you can write the code that serves the “bridging” function from inside your product! This is "custom developed" or "bespoke" integration.
None of these approaches is always right or wrong. You should consider which is best for the different integrations in your portfolio.
Through the rest of this post we’ll talk a lot about integrations and a little about APIs. Still, assume that if we talk about an integration, there are APIs underlying it.
User Considerations
When looking at how/if you should monetize integrations, consider the following.
Integrations are valuable (for everyone).
To quote our friend Cody Sunkel at PartnerFleet, who puts it quite nicely:
Integrations add a ton of value and customers are willing to pay for them. The catch is that they also increase customer satisfaction and make them stickier, so there's value in getting every customer integrated, whether they're paying or not.
Your users will get a lot of value out of the right integrations, executed well. Integrations help users combine otherwise separate software products into a unified technology stack. It helps them be more efficient and effective when working across those products.
Your users want integrations, and you should want to provide them with integrations!
The value for your user is often what drives the idea to charge for APIs or integrations. But, as you’ll see later, you (the software provider) can get a lot of value as well without directly charging.
You should consider how you distribute value across your customer and partner relationships. When money flows as part of that, how or why does it?
Integrations are often required.
When users consider a software product, integrations fall into one of three buckets:
- Must Have - "If integration to X doesn’t exist, I cannot use this product."
- Nice to Have - "It would be helpful if it integrated to X, but I can get by without it."
- Never Knew I Wanted - "What!? This integrates to X!? That could help me do all these other things!"
The “Must Have” category is becoming more common. This is especially true of integrations to core operational systems like ERPs, HRIS systems, or accounting platforms.
The marketing tech software ecosystem is a great example of this dynamic. In the 2022 Martech Replacement Survey, 54% of respondents cited “Integrations and open APIs” as an “important factor” when looking at new marketing technologies. That was the highest cited category and increased 13 percentage points from 2021.
You should consider where your product fits into your user’s tech stack. Which integrations that you (or the other product) need to provide are “must have”? Are there some integrations that, if not provided, make your product unusable?
Integrations (usually) aren’t your core offering.
While integrations are super important, you probably aren't building an integration product. Integration is not the core value proposition. It's an enabler. Note: this is not true if you provide an integration product, like an iPaaS.
You are an ERP vendor providing an operational and accounting hub for businesses. You are an eCommerce platform providing a platform to sell product. You are a CRM helping sales teams organize their sales process. You are one of any number of other things that aren't an integration platform.
All of these examples are heavy into integration. None of them exist to fundamentally provide integration!
You should consider how your user perceives what they pay you for. The likelihood is that they are paying you for what you do best–the thing that is on your homepage tagline.
Is integration a big part of that? Is it a part at all?
Your user already had a perspective on what you are and what they pay you for. Your decision to charge or not charge for integration should factor that in.
APIs are only part of the solution.
The user demand for integrations is clear, but the ways you should fulfill that demand are often less so. It’s common to hear product and partner teams cite, “We have an API,” implying that integration is taken care of.
APIs are an important part of fulfilling your users' demand for integrations. However, APIs alone are insufficient! Someone has to build the integration between the APIs.
Whether you build the integration, your partner does, or you rely on a third party like an iPaaS, someone has to do it. If you aren’t providing it through these means, then the user will have to build it.
Remember, you cannot cross that river without a bridge.
“Paid” features come with expectations.
Users and partners will have a different set of expectations about what they will pay for.
Asher Mathew of Partnership Leaders shares:
If you charge for [APIs and integrations] you have to be clear what you are charging for. We tried a platform fee at [a previous company], and it was not well received because we did not have a developer support/success team.
Imagine eating at a restaurant, and your waiter brings out a piece of cake for dessert. You try the cake, and it’s dry and mealy–not very appetizing.
If the waiter brought it out as a complimentary addition to your dinner, there’s little harm. It’s a little annoying that the restaurant gave you a gross dessert, but you didn’t expect it anyway.
On the other hand, if you ordered and intended to pay for that cake, you’d be pretty unhappy. It would be reasonable for you to send it back or have it removed from your bill.
The same is true of features in a software product, including APIs and integrations. If you charge users for them, your users will expect more from you. That could mean reliability, hands-on support, and more.
Ways to Monetize APIs and Integrations
There are a bunch of different ways you can monetize both your APIs and your integrations. You may even choose to install more than one strategy.
These strategies fall into two categories: 1) charging directly for use or 2) making money indirectly, influenced by their use.
In the following sections, we’ll share some common direct and indirect monetization strategies.
It’s important to acknowledge that this is not a comprehensive list, though. There are many more, including variations on what we included here.
Direct Monetization
Direct monetization means charging your users or partners for an integration or API. You position APIs and integrations as “premium” and likely optional. They also bring with them a more direct ROI for both you and your user/partner.
Some of the advantages of direct monetization strategies are:
- Clearer ROI for you providing the API or integration as a feature
- Likely a clearer ROI for the user or partner, because there’s a predictable cost structure
- You expand your revenue per customer while you expand the value you add
- You can help fund the operational and personnel expenses that come with integrations
Some of the disadvantages of direct monetization strategies are:
- It creates a barrier for your users, so fewer users are likely to adopt the integration
- It creates a higher burden for support
- You have to figure out what pricing strategy works (and accept that you’ll make mistakes)
The following sections will share some of the direct monetization strategies to consider.
Charge for API Access
Charging for API access means that you treat your API as a “premium” feature. It's only available to your customer if it's paid for. This would be with a flat or tiered fee, or at least a fee that isn’t driven by usage of the API (that’s the next strategy).
The amount you charge for API access can vary. It depends on:
- The general price point of your product
- The cost-value trade-off for your users
- Your positioning in the market
This is a common strategy that for products that have a “freemium” model. The API would not be available to the “free” tier, which might have otherwise full access to features. It assumes sophisticated users will have more budget allocated to the problem. Those users will need API access most.
Charge for API Usage
Another way to charge for an API is by its usage. With this strategy, the API is still a “premium” paid feature, but its cost relates to how much it’s used. This is a common pricing model for products that are APIs (Twilio, a messaging API, is a great example).
To charge for usage, you need to identify the metric that defines “how much the API is used”.
One approach is to charge a very small amount every time the user makes an API call. Since API calls happen many times, this amount is usually a fraction of a cent. Products that charge this way often provide discounts for prepaying for API calls. They also usually provide an amount of API calls available for free.
Another approach is charging based on the value of the API call. In this case, not all API calls are equal–the data passed to the API defines the value.
Payment APIs like Stripe are an easy example.
You might make one or ten API calls to execute a payment. That number isn’t important. The size of the payment drives the cost, whether it’s $10 or $1,000. You are charged a percentage of that payment amount, but for the number of API calls.
Another good example of this are systems that process retail orders on a “per order” basis. The number of API calls isn’t exactly important. It’s the number of orders you enter into the system via that API that drives the fee.
Charging for API usage instead of access more ties the cost of the API to the value it provides. It could also make your users cost less predictable. It depends on your user's behavior.
Charge for Integrations Access
Maybe, you provide an API and integrations as parts of your product (hint: you should). You could choose to charge for the integrations instead of the specific usage of the API.
In this case, the API would be free and available to users to work with on their own. You provide an “easy button” with common integrations to systems users will need. In this case, you would choose to charge for access to those “easy button” integrations, not the API.
You may choose to charge directly for integrations, literally as a line item on your invoice. However, it’s more common to include “integrations” as an up-sell feature. You'd include it in a premium pricing tier, along with other up-sell features.
Like with charging for API access, you target your more sophisticated users. These are the ones with more budget and who get more value from integrations.
You can also consider charging by quantity of integrations. Maybe lower tiers get to activate a limited number of integrations than higher tiers.
Additionally, you can tier the integrations themselves. In this approach, you allow access to certain integrations based on the user’s pricing tier. Integrations to enterprise systems like ERPs are often bundled this way.
Charge for Integration Usage
You can also charge for usage or throughput of the integration, instead of charging for access to it. For integrations, this is less common unless you are an iPaaS provider.
This is the same idea as charging per API call for an API, except you charge for the times the integration runs a job.
Here's how that works... Usually an event (like a webhook) or a schedule triggers an integration. Then the integration does its job, which is moving data. You charge for the number of those events.
It's challenging to align integration usage with users' business value, unless you sell an iPaaS. It also tends to be complex to describe to users. This makes it hard for the user to understand what they’re paying for.
Indirect Monetization
Indirect monetization strategies involve understanding how integrations drive revenue upside. You drive revenue without directly charging the customer for the integration or API.
This doesn’t require you to change anything about your customer relationship. You just collect and contextualize data about integration usage. Then you correlate it to revenue growth.
Indirect monetization factors in the influence integrations have on revenue. This includes bringing in new customers or partners and retaining them. It also factors in new, indirect revenue streams that an integration enables.
Some of the advantages of indirect monetization strategies are:
- Your ROI model is not dependent on charging your users more money
- If you provide integrations, you always have these strategies available to you
- They factor in all the value integration has to your company. It includes the less obvious “influenced” value.
Some of the disadvantages of indirect monetization strategies are:
- They are more abstract than direct “dollar for service” strategies
- They use more assumptions. The ROI models are imperfect albeit correct enough to be useful.
- They require data that might not be easy to get.
The following sections will share some of the indirect monetization strategies to consider.
By the way, check out our post about other key metrics that integration helps to drive.
Attract More Users
One of the main ways integration drives revenue is by helping you attract and secure more users. Nowadays, integration is almost always required for software buyers.
The Martech Replacement Survey, mentioned eariler, reinforces this. It found that “integration” was the second most cited reason for replacing a product in the tech stack. (And, remember, the top cited critical requirement was “integration”.)
When prospects consider your product, they'll look at how many integrations you have. They’ll look for how many of those integrations are to other products they already use. They'll also compare it to your competitors.
If prospects consider your integrations before buying, there's a direct relationship. Integrations directly influence whether you win that prospect as a customer. Therefor, you should build an model for how much of a new customer's revenue is owed to the integration.
When doing so, you’ll also need to recognize which integrations are “must have” versus “nice to have”. Required integrations should have a higher attribution percentage than nice-to-have ones.
Check out integrationplanner.com. It's a free tool that helps you think through the revenue impact that an integration can have.
Keep Users Longer
Integrations also create stickier customers. It makes sense. The more integrated your product is, the less likely it is that they’ll want to rip it out. Integrations are like vines that you get to weave into your user’s world.
Data backs this up, too! Products with at least one activated integration increase retention 10-30%. Various other case studies have showed user stickiness with 3 to 5 activated integrations.
Integrations don’t only help with retaining users over the long haul. They also help to reduce the “time to value” (i.e. your user’s time between signing up/receiving the bill and getting value). Put another way, they smooth out user onboarding. The faster you can get them integrated, the happier they are!
Just like with new users, you need to consider how you attribute churn reduction.
It’s reasonable that the integration isn’t 100% of the reason a user sticks around a lot of the time. However, you likely have data to show how many users would churn due to lack of an integration. In that case, you have the argument for a much higher attribution percentage.
The ROI for keeping users is typically smaller than attracting new users. That’s because you have an unbounded opportunity to add new users. You can only prevent the users you have from churning.
All that said, you should consider both. Both have an indirect impact on revenue.
Partnership & Marketplace Fees
You don't have to charge users in order to monetize integrations.
Instead, you could monetize them by charging fees to technology partners. These would be to partners who want to build integrations to you or use your integrations.
These fees generally come in one of two forms:
- Charge for the partnership itself or
- Charge a percentage of revenue generated because of the integration.
Both of these strategies are hard to install if you aren’t a large player in your ecosystem. If there isn’t demand to be your partner, it’s hard to monetize it.
It also begs the question about whether you should charge for partnerships. You receive a lot of benefit for having a strong tech partner ecosystem. Those benefits may outweigh the need to make direct revenue from it. You should consider the cost tradeoffs carefully.
Should you charge for APIs & integrations?
These different strategies for monetizing integrations often boil down to one question. It’s the question, which we hear often, that inspired us to write this post at all.
Should you charge for your APIs and/or integrations?
There is no universally correct answer. Let’s break down how to get to the right answer for your product.
Why You Shouldn’t Charge for APIs & Integrations
Our strong opinion on charging for APIs and integrations is “default no”.
We encourage you to assume you should not charge for API access or integrations. This doesn't mean you never should. This opinion is void of any other context about your users, your pricing model, or the nature of your product.
Integrations are such a powerful indirect driver of revenue. There’s so much upside (most of the time) for harnessing that indirect revenue. The trade-offs of direct monetization usually aren't worth it.
The next section will cover some reasons you should charge for APIs and integrations. Here are a few reasons you should not.
The market won’t bear it.
The simplest reason you shouldn’t try to charge for APIs or integration is that your users won’t pay for it. It doesn’t even matter the reason why or whether it's a fair reason. If users won’t shell out the cash, you can’t make money on it.
Whether this is true will be different for every company. It’s safe to assume that your market is moving in this direction. Users increasingly view integration as an obligation for you, the provider.
Your competitors don’t.
Your competitors may not charge for them. This could be another reason your users might refuse to pay for integrations.
All else equal, users will usually prefer free integrations over paid ones. They often will do so at the cost of quality or depth of features. If the market has set the terms of “free integrations”, it’ll be an uphill battle to overcome that.
Integrations only add marginal value.
Perhaps your integrations aren’t considered mission critical or they only add a little bit of value. In this case it’ll be tough to charge for them.
This is simple cost-benefit analysis. Why would a user pay for something they don’t get much value from, even if it’s more than zero value? More often than not, they’ll just choose not to use it.
It’s too complicated.
It isn’t always easy to install what’s required to measure API or integration usage. You need to if you want to charge appropriately for it. At even a small scale, you must automate it or you run the risk of errors. (Users don’t like when you accidentally charge them too much for a service.)
If you don’t understand how to install this kind of model or the cost is too high, it’s best to not try.
Why You Should Charge for APIs & Integrations
There are some reasons you should consider charging for APIs or integrations.
You are an API or integration provider.
The math is different if your product is an API or fundamentally provides integration (like an iPaaS). Of course you have to charge for API access and/or integrations. What else would you charge for?
You sell data as a product.
If data itself is your product and you use an API to make that available to users, charging for API access usually works. It’s hard to charge for the data. Charging for access to the data (via API) is pretty easy to explain to a user. It also aligns with the value they receive from that data.
The integration has significant internal cost.
You might have to take on an outsized expense to provide the integration. This justifies passing some or all the cost forward to your users. These costs can come in the form of:
- Fees you have to pay to access APIs or data, as a technology partner
- Processing for extremely large volumes of data
- High frequency of data mistakes and errors that must be manually addressed
- Integration to legacy systems that weren’t built to support integration
You shouldn’t burden yourself with unreasonable costs. Most users wouldn’t expect you to, either. This is true, even if you share our "default no" opinion.
The market will bear it.
Perhaps the simplest answer is that you should charge users for integrations if they’ll pay for it. If the market will accept those terms, why not make some revenue?
A word of caution: you leave the door open to competitors offering a comparable integration for free. This is especially true if what you are charging for has a low barrier to entry. You should also consider the tone this sets for your user relationship.
All that said, business is about supply and demand. If the demand outweighs the supply for this integration, then you may be able to monetize it.
---
There's a lot to think about here. You should also check out our previous post on monetizing integrations.
