Help setting up and enforcing daily and monthly quotas

[anannra]

Hello,

We have a "free tier" set up in our api portal, and we ask that users create an APIKEY before they start hitting our API.

We'd like to set up and enforce a daily limit of 10 calls per day, as well as a monthly quota of 100 calls per month. Our assumption is that for a given apikey (created for an app by an end user), that apigee supports policy enforcement at the apikey level.

In essence, we want to limit consumption per apikey to the 10calls/day, but also only allow 100 calls/mo.

In the portal product config, we currently have the config as described in this screen capture :

While our proxy has the following Quote script in place:

<Quota continueOnError="false" enabled="true" name="Q-tg" type="calendar">
  <DisplayName>Q-tg</DisplayName>
  <Properties/>
  <Identifier ref="request.header.x-apikey"/>
  <!-- This line specifies the API key enforcement -->
  <Allow count="100"/>
  <!-- Removed countRef to set a fixed count value -->
  <Interval>1</Interval>
  <!-- Removed ref attribute to set a fixed interval -->
  <TimeUnit>month</TimeUnit>
  <!-- Removed ref attribute to set a fixed time unit -->
  <Distributed>false</Distributed>
  <Synchronous>false</Synchronous>
  <StartTime>2013-08-21 10:00:00</StartTime>
  <AsynchronousConfiguration>
    <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
    <SyncMessageCount>5</SyncMessageCount>
  </AsynchronousConfiguration>
</Quota>

At the moment, these don't seem to be enforced based on testing.

[dchiesa1 · Accepted solution]

Can you try something simpler?

<Quota name="Q-tg">
  <Identifier ref="request.header.x-apikey"/>
  <!-- This line specifies the API key enforcement -->
  <Allow count="100"/>
  <!-- Removed countRef to set a fixed count value -->
  <Interval>1</Interval>
  <!-- Removed ref attribute to set a fixed interval -->
  <TimeUnit>month</TimeUnit>
  <!-- Removed ref attribute to set a fixed time unit -->
  <Distributed>true</Distributed>
  <Synchronous>true</Synchronous>
</Quota>

Changes:

• Quota type = default, rather than calendar.
• Distributed and Synchronous = true

For the former, calendar is fine... If you want to start at the beginning of each month, or the beginning of each day. And the default works by beginning the count at the reception of the first request.  Either way should work fine; which you want depends on exactly how you'd like to enforce the limit. 

For the latter, the documentation recommends that:

In the portal product config, we currently have the config as described in this screen capture :

That screenshot shows that you have specified a Quota configured for the product. But your Quota policy does not reference that configuration data. To get the Quota policy to reference what you configure in the API. Product, you need to use UseQuotaConfigInAPIProduct :

  <Quota name="Q-tg">
    <Identifier ref="request.header.x-apikey"/>
    <!-- replace stepName as appropriate for your proxy -->
    <UseQuotaConfigInAPIProduct stepName="VerifyAPIKey-1"> 
      <DefaultConfig>
        <Allow>100</Allow>
        <Interval>1</Interval>
        <TimeUnit>month</TimeUnit>
      </DefaultConfig>
    </UseQuotaConfigInAPIProduct>
    <Distributed>true</Distributed>
    <Synchronous>true</Synchronous>
  </Quota>

But I don't think your situation is quite like that. You have TWO rate limits you want to use, one for the day and one for the month, and you want to reject the request if either limit is exceeded. The simplest way to do this is enforce TWO quota policies, one with config for 100/1/month, and one with config for 10/1/day. It doesn't matter which order you insert them into the API Proxy. You don't need to use the quota configuration in the product page, and in fact, that configuration is not flexible enough to specify BOTH limits you want to enforce. Instead you may configure just ONE limit.  

[anannra]

ah... I didn't realize I count string together a series of quota policies. ok... I'll try that.

My next question is, how might I be able to enforce these policies where they apply at the account level. With the current setup, a user could create multiple apps, each with their own key, and in theory, make hundreds of calls..... I'm starting to think that enforcing at the account level might be a more appropriate means of preventing revenue leakage. Thoughts?

[dknezic]

Once your Verify API Key policy has run, there'll be a number of other flow variables that will be populated including developer entity related attributes. You could use one of these that are unique to the developer as the quota identifier instead of the key 

https://cloud.google.com/apigee/docs/api-platform/reference/policies/verify-api-key-policy#flowvaria...

[dchiesa1]

Yasssss 

So whatever you (anannra) mean by "account", if you have a data item that uniquely identifies the account , you can use that as the identifier in the quota policy.