Quota on product/Quota Policy on API Proxy/Monetization Set Limits

[#1]

Hi all, anyone knows the difference beetween these three configurations :

1) Quota on the Product : I am actually not able to see anything after configured that on my product

2) Quota policy on the API Proxy: this works an di am able to have a limit on my API proxy calls

3) Monetization Set limits : i have some trouble on configuration of this flow but actually i think should implement the same behaviour of one of the previous Quota point listed above.

Thank you in advance

Regards

Cosimo

[jonesfloyd · Accepted solution]

Hi Cosimo -

1) The quota setting on a product doesn't do anything on its own. You have to reference that value via a variable in a quota policy. For more info on that, see this community post: https://community.apigee.com/questions/1488/how-do-the-quota-settings-on-an-api-product-intera.html Advantages to setting quota on the product for quota policies to reference are

• Quota policies can use a uniform setting across all API proxies in the API product.
• You can make runtime changes to the quota setting on an API product, and quota policies that reference the value automatically have updated quota values.

2) awesome

3) For monetization limits, I'm guessing you've already seen this doc: http://apigee.com/docs/monetization/content/set-limits. You can also impose transaction limits via rate plans. (Please provide more details about where you're having trouble.)

Transaction limits in monetization mixed with regular quota could get tricky. If your API proxies are going to be used only for monetization, it may be better to not use quota policies, unless you want to use them as a fallback insurance plan, such as setting quota limits higher than your monetization transaction limits and rate plan limits. (Somebody else feel free to provide more guidance about this.)

Hope this helps.

Floyd

[jonesfloyd · Accepted solution]

Hi Cosimo -

1) The quota setting on a product doesn't do anything on its own. You have to reference that value via a variable in a quota policy. For more info on that, see this community post: https://community.apigee.com/questions/1488/how-do-the-quota-settings-on-an-api-product-intera.html Advantages to setting quota on the product for quota policies to reference are

• Quota policies can use a uniform setting across all API proxies in the API product.
• You can make runtime changes to the quota setting on an API product, and quota policies that reference the value automatically have updated quota values.

2) awesome

3) For monetization limits, I'm guessing you've already seen this doc: http://apigee.com/docs/monetization/content/set-limits. You can also impose transaction limits via rate plans. (Please provide more details about where you're having trouble.)

Transaction limits in monetization mixed with regular quota could get tricky. If your API proxies are going to be used only for monetization, it may be better to not use quota policies, unless you want to use them as a fallback insurance plan, such as setting quota limits higher than your monetization transaction limits and rate plan limits. (Somebody else feel free to provide more guidance about this.)

Hope this helps.

Floyd

[#4]

Thank you Jones, I got it. Now I am still facing issue on create a good monetization flow. Any suggestion on the other my quetion?

Best regards

Cosimo

[jonesfloyd · Accepted solution]

Hey Cosimo - Here are some thoughts on using monetization limits. The assumption here is that we're talking about limiting the number of monetized transactions.

Rate plans

I'd start with thinking about your rate plans first, just to know what kind of transaction volume you might be limiting with them. There are a few places where transactions can get blocked because of rate plan limits:

• Freemium plans: If you provide free API use, one option is to allow free API calls up to a certain number of transactions. For example, let's say your freemium plan offers 100 free calls. When an app reaches 100 calls, any additional calls are rejected.
• Rate Card plans that are Volume Banded or Bundles. With these, you can charge developers based on groups of API calls. If you set an upper limit for the number of calls in the last bundle, additional calls past that limit are rejected until the period resets (for example, a new month starts and the number of calls resets to zero). In this scenario, let's say you had a bundle limit of 10,000 calls. Now you have an idea of the maximum volume you're allowing in your rate plans.
• (When a rate plan expires, but this probably isn't relevant for this discussion.)

Limits

Once you have an idea about the amount of transaction volume you're already limiting through your rate plans, you can set limits.

If some or all of your rate plans don't enforce any limits (for example, if the last group in your Rate Card bundles doesn't have a limit ("unlimited"), or if your Rate Cards just use a flat transaction rate, use limits to restrict transaction volume.

If your Rate Card bundles *do* have limits, like I mention above (100 freemium and 10,000 in bundles), and you want to set limits to handle all other unlimited rate plans, you won't want to set limits that are less than 10,000, because that would stop API calls on those 10,000-call plans before 10,000 is reached. OR, you could target only the non-10,000-plan packages with limits.

Quota?

If you have quota policies on the API proxies you want to monetize, you could see how setting lower quota limits (for example, below 10,000 calls a month) would cause trouble. So for your monetized proxies, I'd recommend not using quota if you're going to set monetization limits with rate plans, limits, or both. But using Spike Arrest is always a good idea to protect against traffic spikes.

Hope this helps a bit more.

Floyd

[#6]

Hi Floyd, what a about inteasta on how to be configured the Monetization flow in order to print a billing report?

[jonesfloyd]

Hi Cosimo - Can you please provide a bit more description? I want to better understand your use case. Thanks!