Different quota limits for each proxy in a bundled API product

[sarfernando]

Are there valid use cases where we may need to apply different quota limits on proxies bundled in a single API product? Or is it recommended practise to create a product per proxy to achieve this?

We are also looking to apply quota policies at resource level and method level for each resource. What would be the best approach for this ? Thank you.

[dchiesa1 · Accepted solution]

Are there valid use cases where we may need to apply different quota limits on proxies bundled in a single API product?

Possibly there are valid use cases. I don't know what they might be though...

There are ways to achieve per-proxy quotas.

Today the quota limit defined on an API Product is a single quota number.

How it works at runtime:

• a request arrives at the API Proxy
• the proxy invokes either VerifyApiKey or OAuthV2/VerifyAccessToken;
  this verifies that the key or token provided is authorized for this proxy and resource path.
• the proxy then invokes Quota policy. If the designer wants to enforce a quota based on the quota limit defined in the API Product, then the quota policy must reference context variables that have been implicitly set by the preceding VerifyApiKey or VerifyAccessToken.

If you want to apply a different limit for each proxy in a product, you can do that. The way to do it:

• define custom attributes on the API product representing the quota limit for each proxy. For example

  custom attr name	value	meaning
  proxy1	100	quota limit for proxy1
  proxy2	1200	quota limit for proxy2

• When VerifyApiKey or VerifyAccessToken is called, these custom attributes are loaded into context variables.
• Within each API Proxy, insert a Quota policy that references THOSE variables, rather than the standard variables for an API product.

---

We are also looking to apply quota policies at resource level and method level for each resource.

If you want to do something more elaborate, then I'd suggest externalizing the quota limits on the per-resource or per-method basis into a JSON or other data format. You could attach that as a custom attribute to the API product too.

Then you would need to run a little JavaScript step that performs a JSON.parse() on that value, and then sets the appropriate context variables for the given resouce path and verb (etc) by examining request.verb, proxy.pathsuffix, and comparing that against what is in the JSON blob.

Set variables like "quota_limit" and then invoke the Quota policy using that variable.

[dchiesa1 · Accepted solution]

Are there valid use cases where we may need to apply different quota limits on proxies bundled in a single API product?

Possibly there are valid use cases. I don't know what they might be though...

There are ways to achieve per-proxy quotas.

Today the quota limit defined on an API Product is a single quota number.

How it works at runtime:

• a request arrives at the API Proxy
• the proxy invokes either VerifyApiKey or OAuthV2/VerifyAccessToken;
  this verifies that the key or token provided is authorized for this proxy and resource path.
• the proxy then invokes Quota policy. If the designer wants to enforce a quota based on the quota limit defined in the API Product, then the quota policy must reference context variables that have been implicitly set by the preceding VerifyApiKey or VerifyAccessToken.

If you want to apply a different limit for each proxy in a product, you can do that. The way to do it:

• define custom attributes on the API product representing the quota limit for each proxy. For example

  custom attr name	value	meaning
  proxy1	100	quota limit for proxy1
  proxy2	1200	quota limit for proxy2

• When VerifyApiKey or VerifyAccessToken is called, these custom attributes are loaded into context variables.
• Within each API Proxy, insert a Quota policy that references THOSE variables, rather than the standard variables for an API product.

---

We are also looking to apply quota policies at resource level and method level for each resource.

If you want to do something more elaborate, then I'd suggest externalizing the quota limits on the per-resource or per-method basis into a JSON or other data format. You could attach that as a custom attribute to the API product too.

Then you would need to run a little JavaScript step that performs a JSON.parse() on that value, and then sets the appropriate context variables for the given resouce path and verb (etc) by examining request.verb, proxy.pathsuffix, and comparing that against what is in the JSON blob.

Set variables like "quota_limit" and then invoke the Quota policy using that variable.

[sarfernando]

Thank you for the detailed answer!

[#5 · Accepted solution]

@Sarah If you want to put different constant quota values for each proxy then you can set your quota at proxy as literals instead of reference values. If you want in reference, then you can set custom attributes at developer app, developer or product level for the different quotas, then after API key verification, you can use those in quota policy of different proxies as reference.