topic Crossing API Rate Limit & charges in Network Platform API

Crossing API Rate Limit & charges

flyingframes — Thu, 21 Oct 2021 22:38:00 GMT

If the API calls happen to be more than the free tier of 10 calls per second per org, is there a metering & charge possible?

https://developer.cisco.com/meraki/api-v1/#!rate-limit

Each Meraki organization has a call budget of 10 requests per second.
A burst of 10 additional requests are allowed in the first second, so a maximum of 30 requests in the first 2 seconds

Re: Crossing API Rate Limit & charges

BRUCE NEWTON — Fri, 22 Oct 2021 03:50:21 GMT

@flyingframes, no there isn't (well, not that I've ever discovered). Everyone is treated equal with regards to API calls - one free tier for everyone.

Re: Crossing API Rate Limit & charges

sungod — Fri, 22 Oct 2021 17:29:03 GMT

As above, there's no charge.

What happens is that 'excess' calls will return code 429 to indicate that the call failed due to the rate limit.

Any application that might make calls frequent enough to hit the rate limit needs to be coded to back-off and retry appropriately.

If you use the Python Meraki library, it includes handling of rate limiting, though it's not always sufficient (i.e. when using the aio library).

Re: Crossing API Rate Limit & charges

Philip D'Ath — Fri, 22 Oct 2021 19:46:46 GMT

The aio portion of the Python library is aware of 429's and will back off and retry automatically.

Re: Crossing API Rate Limit & charges

sungod — Sat, 23 Oct 2021 10:12:40 GMT

I've found it still breaks down under load, such as when nested to get per device/other element data for hundreds of networks in 'one' aio call, then calls will intermittently fail with the error "429 Too Many Requests".

To handle that, inside the sub-functions there's a capped exponential backoff and retry if a failure occurs.

This issue certainly was in v0 and beta/early v1, perhaps the library code improved since then? But I've not tried running without the extra error recovery as it also helps gracefully recover from other transient errors that can occur.

This is used in scripts that daily pull various performance data for analysis for large organizations that we manage, it's important that it operates without human intervention to recover/re-run. Any time there's a 'new' error found, I try to add code to avoid/recover.