How to monetize your API with Project X

Intro

If you’re not a big fan of writing boilerplate code, you might find interesting the approach we’ve taken at Project X to help API providers monetize their APIs.

It combines a custom-built billing engine designed specially for API use-cases, a smart API gateway capable of automatic usage tracking and advanced consumption control, and a UI where the whole system is configured.

This approach enables anyone to start charging users for access to an API without writing a single line of boilerplate or integration code.

What does the overall process look like?

Step 1: API

First, you need to add your API in the UI.

You can do that either manually, providing all the necessary information about the API: base URL, endpoints, etc., or by importing an OpenAPI specification file in JSON or YAML format.

Step 2: Products

Second, you need to define your API products. Think of each product as a subscription plan which customers can subscribe to.

Before, products were called “Subscription plans”, but since the term is nowadays associated with subscribing to only one API which is not the case with Project X — you can subscribe to two or more APIs with a single subscription — they have been renamed to “Products”.

When creating a product, you need to pick the endpoints available to the user. The product can include any combination of endpoints from any number of APIs.

It means, users might be able to subscribe to several APIs at once and use them with one single access key, if you decide to include more than one API in the product.

Another use-case for this feature could be separating basic and premium endpoints. If you’d like to exclude some endpoints from basic product and include them only in premium, that can be done easily: just select the ones you’d like to enable.

Once you’ve selected endpoints and created a product, it’s time to define other limitations.

Quotas

Quotas are the workhorse of Project X engine.

With quotas you can impose limits on almost any product metric. Project X API Gateway will make sure your customer never exceeds the limits configured for the product.

For every single API call it will dynamically calculate how much of each quota this particular request uses.

There can be several quotas added to a product which allows you to configure complex product offerings.

Each quota, in turn, can have any number of linked endpoints. Only the linked endpoints will be using the quota and, once the quota is exceeded, the API Gateway will reject subsequent calls to these endpoints.

Thanks to the flexibility of the API Gateway, you can link endpoints from different APIs to a single quota.

For instance, if you need to impose a common limit on a number of calls to several APIs, or if you’d like to sell “credits” that should be used whenever a call to any of your APIs is made — this is the way to go.

Rate limits

Rate limits are restrictions imposed on the number of calls per rolling time window. Similar to quotas, they can be imposed on any combination of endpoints, even cross-API.

So again, if you need to protect more than one API with a rate limit — Project X allows to configure that in the UI, quick and easy.

Rejection rules

Many API providers would like to offer premium features, available only on bigger plans.

That’s what rejection rules are for. They define what calls should be rejected by the API gateway instead of passing them to your API.

Let’s say, your endpoint has a query string parameter, a parameter in the JSON request body or in a request header.

And if it exceeds some pre-defined value, the request must be dropped.

Example

Let’s say, you have an endpoint GET /historical?days=7

In the basic product you allow up to 7 days of historical data, and on the premium plan it’s 365 days.

Then rejection rules for the products would be like “if the query string parameter “days” value is greater than 7, reject the request” and “if the query string parameter “days” value is greater than 365, reject the request”.

Path parameters (e.g., /stats/{startDate}/{endDate}), query string parameters, values from request payloads and request headers — all that can be used in the rejection rules in order to implement premium features for your products.

Step 3: Pricing

Prices in Project X are linked to quotas and define the price per quota unit. The only exception is flat fee: it’s charged at the beginning of each billing period no matter what.

If a price is metered, the final invoice will be issued for the actual usage of the quota. If a price is not metered, the customer will be charged for the full quota volume, as defined in the product.

Project X supports the following price models:

1. Standard: the same price for each quota unit.
2. Package: customers are charged for a package of N quota units. If package size is 1000 and the customers have used 500 quota units, they’re still charged for the whole package of 1000.
3. Graduated: tiered pricing model. Each tier has its own price per unit and the used quantity falling into that tier is multiplied by tier price. Then the total is summed.
4. Volume: tiered pricing model. The total number of quota units is multiplied by the price of the tier the total number of quota units falls into.
5. Flat fee: the same amount charged at the beginning of each billing period.

See Stripe’s explanation on tiered pricing models: https://stripe.com/docs/products-prices/pricing-models#tiered-pricing

You can add as many prices to your product as you need. Common examples are monthly fee + price per call, annual fee + monthly pay per use, etc.

The billing engine will calculate the amounts and issue invoices which customers are able to pay.

Step 4: Stripe account

Project X is already integrated with Stripe, so you don’t have to do that yourself. It will initiate payments for invoices issued to your customers and Stripe will take care of processing them.

Thus, in order to collect money with Project X you need a Stripe account and have to provide your Stripe keys which Project X securely stores in encrypted form.

Payment status updates from Stripe are processed by Project X, invoices are marked as paid and subscriptions extended automatically.

Step 5: Landing page

Now that you’ve configured everything, it’s time to present your API to the world. However, the “Subscribe” buttons on the landing page are still not working.

In order to obtain a self-service checkout URL for the buttons, go to the respective products’ dashboards and grab the URL from the field “Checkout URL”. Use it for the “href” attribute and that’s it!

Now just publish your landing page and start hustling. Project X will take care of your customers after they click the button.

Feel free to register and try it yourself!

In-depth docs can be found here.