MagicAPI

Understanding Products

Products are the basic unit at MagicAPI that you use to sell APIs. Each Product has an attached "productConfig". This productConfig is "immutable" and only new versions are created on each update.

Pricing Plan Config allows you to offer different types of Products suited for your Business Use-Case. You can offer a limited FREE version or offer a pay-per-use Plan. Some of the more frequently used Pricing Plan configs are described below: A Product can be configured in many different ways.

Product.ProductConfig.PricingPlan Each Product has a ProductConfign. Each ProductConfig has a pricing plan attached to it.

You can create various kinds of Pricing Plans. Various types of Pricing Plans

Various types of Pricing Plans

These plans are not really types but various examples of the Pricing Plan configured differently. You can configure the PricingPlan of a Product in whatever way you may like.

1. FREE:

Settings:

  • Pricing: $0/month

  • Limited API Calls

  • Hard LIMIT

  • No Credit Card Required

This Pricing Plan allows API Sellers to offer a free product that enables users to experience the platform without providing credit card information. Typically, this plan is limited to a few hundred API calls per month.

2. Pay Per User:

Settings:

  • Pricing: $0/month

  • Large number of API Calls

  • Soft LIMIT with Overage Charges

  • Credit Card Required

This Pricing Plan allows API Sellers to offer a product where charges are incurred at the end of the subscription cycle based on usage, calculated as the number of API Calls multiplied by the Cost per API Call.

3. Subscription:

Settings:

  • Pricing: Greater than $0/month

  • Defined Number of API Calls

  • Hard LIMIT with No Overage Charges

  • Credit Card Required

This Pricing Plan enables API Sellers to provide a straightforward subscription product. Once the customer reaches the allocated quota of API calls, they will receive a 429 error.

4. Subscription with Overage:

Settings:

  • Pricing: Greater than $0/month

  • Defined Number of API Calls

  • Soft LIMIT with Overage Charges

  • Credit Card Required

This Pricing Plan allows API Sellers to provide a subscription product where customers are charged based on the overage amount once they exceed the allocated quota of API calls.

Product Access:

While creating a product you can configure it accessible only through a certain way. These are the various types of visibility/access patters we support. If you want any other way then let us know, it's quite easy to add new access ways.

  • public: Anyone can see on Portal and subscribe

  • private: Only emails on the private access list added by the admin can be seen and subscribed. Users can always see products they have subscribed to.

  • restricted: Anyone can see but only admin-approved users can subscribe. Users can request access by clicking on "Request Access" and once the admin approves, they can see the Subscribe button. enterprise A dummy product that links to a "Calendly" link or a Form. Used to display the "Talk To Us" button with that link.

Product Versioning

In APIs, versioning is a big problem. This is how we solve this at MagicAPI for you and your users. Products are the basic unit at MagicAPI that you use to sell APIs. Each Product has an attached "productConfig". This productConfig is "immutable" and only new versions are created on each update. Users are encouraged to subscribe to the latest version. But older versions are not broken.

So for example:

User subscribed to -> Product (version:0) Then admin makes a change in the Product like apiLimit from HARD to SOFT. This will create a new version (version 1). When a user subscribes to a Product, they subscribe to a specific version of the Product i.e. to a specific ProductConfig.

Hence you can make any kind of changes to your product as all current users won't be affected by change in the Product. They would be subscribed to a different version of your Product. You can check what version which user is using on Analytics or you can send MagicAPI a support request. We always reply to every email.

When a new version is released it would change the Subscribe button to "Upgrade to version X" on the User Portal. On clicking the changes are applied in a git diff fashion.

So if you made changes like -> 100 APICalls -> 200 API Calls. This won't affect current usage.

On pricing change, the user is charged a "difference" from the version they are subscribed to. So if their previous subscription was 9 and now it's 19 then the user is charged 10 USD.

Product Groups

You can create a group of products that only allow one active subscription per group:

For example: a store might list various plans of a given API: (9)Free, (49)Starter, (129)Pro or some other public or private product.

The user can only upgrade or downgrade between these products. API Sellers can use private products to offer a private product to specific users as well in a group.

Payment/Charge behavior:

We will include all usage from the previous plan into this new plan.

Let's understand how we charge on Upgrade/Downgrade between Products with an example:

We have two different products in our productGroup. Product 1 (Starter)

  • name: starter

  • subscription per month: $9

  • API Calls: $10,000

  • Overage: $0.003/api_call

Product 2 (Pro)

  • name: pro

  • subscription per month: $49

  • API Calls: 50,000

  • Overage: $0.002/api_call

Let's assume the user is subscribed to the starter plan at 9 USD per month and they have made 30,000 API calls before the end of current subscription. Now 9 USD plan only includes 10,000 API calls and extra API calls are charged at $0.003/api_call.

Their bill will be:

  • Total API Calls Made: 30,000

  • Included: 10,000

  • Overcharge: 20,000 * 0.003

  • Total= 60

Now, if they upgrade to the pro plan their end-of-month bill will be:

  • Total API Calls Made: 30,000

  • Included: 50,000

  • Overcharge: 0 * 0.003

  • Total: 49 ( Difference 49-9 = 40 is charged on Upgrade click and $0 overage charged at end of the month along with next month's subscription charges if still subscribed.).

So by upgrading, they will be charged less. We think this behavior is better for a long-term relationship. We don't want to charge our users unfairly. If you have a better idea please do email us we love every chance we can improve.

MultipleProductConfigs Product

These types of Products allow multiple ProductConfigs to be included in a single Product and available through a single Subscription.

UseCases:

  • Integrations: You may want to connect various APIs with different schemas and different basePathURLs.

  • Availability: You may want to offer some APIs with a different basePathURL.

  • WhiteLabel/resell: You may want to sell some APIs from other sellers.

  • Tiered Pricing: You may want to have different Pricing plans for different paths such as tiered pricing explained below.

For this kind of Product, each product can have one or more ProductConfigs.

One of the ProductConfig is "parent" and the pricing, apiUsage, overage will be used from this.

Each other ProductConfig can overwrite and set a different limit or a different kind of pricing plan:

Example Product with multiple Product Configs:

Main API: Price: 9 USD/month.

parent: /v1/extract

  • name: /extract

  • subscription per month: $9

  • API Calls: 10,000

  • Overage: $0.003/api_call

/v1/predict

  • subscription per month: Will use parent's pricing i.e. 9 USD per month.

  • API Calls: 0

  • Overage: $0.002/api_call

/v1/process

  • subscription per month: Will use parent's pricing i.e. 9 USD per month.

  • API Calls: 10,000

  • Overage: $0.002/api_call

/v1/getResult

  • subscription per month: Will use parent's pricing i.e. 9 USD per month.

  • API Calls: 100,00

  • Overage: $0

/v2/predict

  • subscription per month: Will use parent's pricing i.e. 9 USD per month.

  • API Calls: 10,000

  • Overage: $0.002/api_call

/v2/process

  • subscription per month: Will use parent's pricing i.e. 9 USD per month.

  • API Calls: 100

  • Limit Type: HARD

/v2/getResult

  • subscription per month: Will use parent's pricing i.e. 9 USD per month.

  • API Calls: 100,00

  • Overage: $0

Each new ProductConfig can use the same or different API Source. The end user will not know that they are calling multiple different APIs. MagicAPI serves as the gateway and proxy layer.

The API paths will be displayed with API-prefix-based grouping. Example:

  • /v1/

    • /v1/extract

    • /v1/login

  • /v2/

    • /v2/extract

    • /v2/login

Appendix:

Overage: This means the cost per API calls that exceed the allowed API calls in a given Pricing Plan.

PreviousCustom UsageNextAPI Keys

Last updated