A Guide to Turn on API Monetization

Let’s evaluate if you want to build a billing system in-house using existing payment processors such as Stripe or choose an outside vendor to handle complex usage-based pricing models. In this article, we’ll discuss the cost, time, and resource considerations to launch a fully productionized API with usage-based billing, entitlement management, invoicing, analytics, and great customer experiences.

For teams looking to build a scalable, usage-based API billing and monetization, we first want to consider three things: 1) the complexity of your pricing model, 2) whether you sell your API via self-serve or sales-led approach, and 3) the overall maturity and stage of your organization.

Regarding complexity, API products sold on a per-seat basis or charge a single rate across any amount of API calls are fairly straightforward using existing Stripe solutions. One note to make is that for APIs that include rate limits, gated features, or customer portals, Stripe will not support such features. Regarding flexibility, editing pricing models in real-time, price experimentation tools, or custom plans for individual customers would also not be supported.

For API products that support more complex pricing models with add-ons such as endpoint-specific pricing, coupons, discounts, and product bundles - existing billing tools will most likely fall short here.

As for delivery, API products that are not sold to only a small number of high LTV customers (such as insurance companies) or delivered via self-checkout offering are best suited for using an outside vendor. Support for complex pricing models is needed, whereas automating invoicing and billing calculations will set your team up for success.

If you sell your product via self-serve, this is a tough problem to overcome. Managing many users on different plans, where plan upgrades, downgrades, coupons, free trial periods, and more are inevitable - having a usage-based billing provider to handle these specific needs will save your engineering and finance team headache and boost the customer experience for your end users.

Most common payment processors, such as Stripe or Adyen, likely won’t offer the tools or pricing flexibility to support usage-based pricing. Support for tracking customer usage history and gaining insights into usage-based for individual customers and plans are limited or missing entirely. Support for pricing plans with multiple metered items, add-ons, and paid trial periods are missing, whereas usage tracking and modifying plan details can be complicated or similarly missing from the feature set.

A second element is around trusting your data. We spoke with a customer who utilizes Stripe and discovered inaccurate usage tracking shared with them by Stripe, resulting in a total lack of trust in any of their usage tracking metrics.

Other payment processors, like Adyen, may support subscription billing but have no native support for usage-based tracking or complex tiered pricing models.

A common theme we have seen from companies monetizing APIs is to shy away from issuing complex pricing plans, segmenting by endpoint permissioning and adding additional billable metrics, and analyzing this data in an accurate and consumable way to iterate on pricing offerings. The core use case of native payment processes is not in this market, and relying on less-than-ideal tools to charge can significantly hurt your ability to drive revenue.

For teams that want to empower their users to pay for their products on an entirely usage-based approach with add-on elements, choosing a vendor to solve this specific problem is your best bet. Some of these elements are as follows:

If your business chooses to launch API monetization in a usage-based fashion, choosing an outside vendor like Archetype empowers your team to launch any flexible pricing plan in minutes, including onboarding and a quicker ramp curve allows your team to focus on core product and pull insights to iterate on pricing and product quicker.

Simple back-of-napkin math may drive you to a number based on cost comparison. If you think a fully managed API usage tracking and monetization platform can be built with X engineers in Y months, you can compare that number to an outside vendor's costs.

Regardless of where your estimations lie, let’s explore some other things to consider.

A solution will take collaboration from many teams. For mature companies, ensure that your teams across finance, engineering, product management, sales & growth, and the executive committee & CEO are aligned and have the bandwidth to focus on a new product like API monetization. For earlier teams, the focus should be on speed of launching products, loss of momentum, split in team time & direction, and maintenance costs going forward.

Many PMs will struggle to push a new product, be strategic in their efforts, and have influence over the organization and their teams to follow through on a relatively large new lift.

Almost all software firms will face a strict constraint on engineering resources. Reallocating existing engineering talent from the core products to a new API usage tracking and monetization tool might become a distraction for the business. Adding a new product developer life to a preexisting backlog can become overwhelming and create an even larger distraction for the team.

Time to market can be costly in two ways. The first and clearest is that taking additional time to change API pricing plans and drive new revenue is a loss of revenue in the short term. If you estimate your new API usage-based billing strategy will drive revenue up 20% compared to your MRR today, waiting 12 months to launch will be a loss of revenue in the short term. Ouch! A second issue when considering time to market is your competitors. If others are investing in the space, their API usage-based billing and real-time usage tracking/analytics tools might be key selling points for getting customers on their platform.

Some ancillary considerations to keep in mind are the difficulty and costs of hiring good engineering talent in the current market climate, sharing knowledge across many teams can be hard in a remote-first environment and/or across multiple time zones. Hiring engineers with specific skill sets and willingness to build, test, iterate and manage a scalable billing stack is quite tricky. Additionally, the ability of your team to select new technologies and make critical decisions regarding tech that is not core to your product or in a field that sits outside your team's core skillset is difficult.

Now, should you have considered everything above and choose to build a solution in-house, we can share some snippets of advice to keep in mind as you plan to build your new API usage-based billing infrastructure. Five key points are below:

Whatever infrastructure you choose, make sure you can price your API on the metrics and price points that are best for your customers and fully optimize for driving revenue. Don’t allow the complexity of billing models to limit your ability to exploit maximum value from your APIs, or have your team resort to general access subscription plans, as building the correct pricing models is too difficult.

Security, compliance, and strict guardrails around endpoint permissions are essential. Allowing users to gain access to your product due to under-optimizing restrictions can create a security risk.

Before product deployment, ensure your infrastructure is scalable, QA-tested, and in a position to be maintained in the future. Accessing these costs on an ongoing basis will help you decide the actual cost of working with an outside vendor or hacking together internal solutions.

Analytics, churn, and all other usage metrics are the core for experimenting, optimizing pricing, and upselling your customers. Usage-based billing models tend to be highly flexible and allow your infrastructure to track these usage metrics and adjust pricing on the fly will enable your sales/growth teams to drive more revenue. If modifying pricing takes significant time and effort, or if pricing changes are made in the dark with limited information, this alone might make sense to rely on an outside vendor to support your usage-based billing needs.

If your sales or finance teams need to use your pricing tools, UX and overall usability need to be a focus. We have gotten direct feedback from an API-first company that AE usability is key to their vendor selection. If tools are hard to use, the sales team won’t adopt them, and your initiative might stall.

When launching a pricing strategy for your API, choosing a plan that works best for your product and customers is essential. You do not want only to support a plan that Stipe or other payment processors provide. Using a tool like Archetype can allow you to optimize which pricing models work best for your product and easily spin up plans to support this.

As your API pricing models become complex as you scale, having your invoicing and revenue recognition practices automated is essential. We have seen teams poorly scale and hire additional financial headcount to solve problems that could have been avoided by using a proper revenue management partner.

If you want to monetize your API, turn on usage-based billing, launch self-serve checkout, and automate a ton of revenue operations or financial work for your APIs, reach out at sales@archetype.dev to learn more. We are excited to show you a product demo and share insights on how we can drive revenue, save your engineers months and go to market faster.