Products are at the heart of Nadles. They define all aspects of your customers’ future subscriptions. Think of them as subscription plans.
Nadles Products define resources/endpoints/features that your customers have access to, various limitations that apply, and pricing. A single product can include any combination of endpoints from any number of your APIs — and Nadles will provide access according to the rules defined in the product. Endpoints not included in the product are unavailable for customers subscribed to that product. Nadles API Gateway will reject requests to these endpoints. When customer subscribes to a product, Nadles issues a new API key, and the customer is able to access all endpoints in the product using a single API key, even if there are several APIs included. There are several important questions to answer before configuring your products with Nadles.

​
What do I include in the product?

A product on Nadles can be comprised of:
  • A single API. Users subscribe and use API keys issued by Nadles to access it.
  • Several APIs/API bundle. In this case the user will be able to use the same API key for all APIs in the subscription.
  • A subset of endpoints of an API. The user will be able to access only the endpoints included in the product. This is useful for the case, when you are going to split endpoints into basic and premium.
    ExampleFor a currency exchange rate API, you might want to grant access to historical data on a premium plan only.In order to achieve that, you exclude the endpoint returning historical data from the basic product, but include it in the premium product.
  • Any combination of endpoints from any number of APIs. This allows for maximum flexibility when configuring your products.

​
What do I charge for?

Modern best practices in API productization advise, instead of charging for a synthetic “number of API calls” metric, to charge for the actual value the customer gets from your API (why?). Here are some examples of product metrics:
  • Number of images compressed by your API
  • Number of characters translated by your AI translator
  • Number of minutes of audio generated by your Text-To-Speech engine
  • Number of e-mails/SMS sent via your API
Using product-relevant names for metrics lets your customers easily understand the offer and choose the right product to subscribe to. Any product metric can be configured and used to bill your customers with Nadles.

​
How do I structure my pricing?

Do I apply usage-based pricing model? Do I charge a flat fee? How often do I charge? Should there be a free tier?

​
What limitations should I impose?

There is a big variety of limitations that can be imposed on API products. By carefully thinking those through, you offer your customers fair terms that satisfy their needs and are equally profitable to your and them.

​
Limits on billable metrics

Nadles allows to impose limits on billable metrics and periodically reset quotas after a configured period of time. Here are some examples of quotas that can be defined in your products:
APIQuota
Generating audio from text100 of minutes of generated audio per month
Image compression100 compressed images, 1GB of processed data per month
AI-powered translation1 000 000 translated characters per week
E-mail, SMS API1 000 sent e-mails/SMS per month

​
Limits on input parameters

Sometimes it might be useful to limit the range of input parameters in basic products, while allowing the full range of values in premium products.
Example
APIParameterBasic productPremium product
Weather APIHistorical datamax. 10 daysno limit
Mortgage calculatorRepayment intervalsMonthWeek, 2 weeks, month, year
Image recognitionInput formatsJPEGJPEG, PNG, TIFF, RAW
Such limitations can be imposed using rejection rules that allow you to make Nadles reject requests based on and product-scoped request/response transformations that allow you to modify requests in order to, for instance, replace a query string parameter, a value in JSON body or header with some default value.