Quota Expiry Time

I have a quota policy type=flexi that I've configured to reset every 12 months in my API.

I did API calls which were a few weeks apart and noticed that the ratelimit.QuotaEnforceLimits.expiry.time are different between the calls (e.g. the first call I made had expiry.time=1581654507421 and the next call I made 2 weeks later had expiry.time=1583212136349).

Shouldn't the expiry.time be the same for the two calls since the quota is not due to reset yet?

0 5 356
5 REPLIES 5

Yes, what you say makes sense, but ... Gee, I don't know if a 12-month quota is supported.

It looks like it reset after 1 month.

Maybe you can re-design your limits to have N/12 calls in one month, rather than N calls in one year.

Thanks for the response. Is there a maximum allowable interval for timeunit=month?

Our business logic is for a free trial product which lets an app make 1000 API calls (ideally within 1 year). So the app can do all 1000 calls in one go or they can space it throughout several months.

The Quota policy in Apigee edge is not designed to enforce that kind of model. It is more suited to rate limiting over shorter terms, with higher scale.

(1000 for an entire year is not very much. )

If I were doing this I would use a backing store like Firebase Firestore. Keep a document or record for each customer and increment the count for each call.

Thanks for the response again, Dino.

I've also noticed that using the 12-month quota setting, the quota keeps resetting within less than a month (around 13-17 days). Is this expected behavior?

Not expected by me. I would think it would last longer than that. But... I haven't tested multi-month quota counters, and I don't know of any customers who use that long of a time interval.

I know it's documented, so we would expect it to work, from that perspective. But I've never tried it.

If you find this limitatoin to be egregious, you can file a support ticket and ask them to file a bug on your behalf.