We've increased the per-organization dashboard API call budget ⏩⚡📈

[John_on_API]

Ever wish you could go faster?

Well, now you can! We are thrilled to share that we've doubled the API call budget to 10 calls per second per organization (from five) for meraki.com customers at no additional cost.

Who's impacted?

All Meraki customers who use the dashboard API.

 

What's the impact?

If you were encountering API responses with HTTP code 429, which required you to wait and resubmit the request, then you will see fewer 429 responses with your existing API usage. If you were not encountering 429s, then you will not see any difference, but you are less likely to encounter 429s overall if you increase your API usage, such as adopting an app from our Meraki Marketplace.

 

When's this happening? What do I have to do?

No change is required on your end; this is already rolled out and available immediately! Did I mention it's free? Just one more benefit of your existing Meraki licensing.

 

What's next?

We're excited to hear how this change improves the developer experience, so please let us know in the comments!

Thank you for choosing Meraki. 🤠🚀

[Alisdair85]

Great news @John_on_API this is certainly Happy Friday news! Looking forward to ramping up our provisioning rate to warp speed! Thanks for posting.

🚀

[PhilipDAth]

That is a huge step in the right direction.  That is going to make a whole lot of things possible now, especially around MV image processing.

Here is my problem.

At the moment when I want to do things like number plate recognition for drive-throughs and the like, I can do it ok for really small Meraki customers.  For other customers I have to create an org "per network" to store the cameras.  So if I have 200 networks, I end up with 200 orgs, so I end up with a rate limit of 1000 calls per second (now 2000 calls per second).

A rate limit of 100 calls per second should be enough for this case.

What I would really like is to just put the cameras in the actual networks, all in one org, so I don't have to work around the limit.  This would be much easier for the customers as well.

Either way - I'm going to use the same number of API calls per second.  It's up to you how hard you want to make it for the customer.

[Greenberet]

Great News, but to be honest that's still not high enough.

10 might be a good start for a default limit, but it should be possible to have higher limits. @PhilipDAth made a perfect example why a higher limit is needed.

Action Batches were a nice start to reduce the number of api calls, but they are having a big problem. Not all api calls are supported inside of action batches!

IMHO there should be some kind of process e.g. via a support case to increase the limit for an organization.

1. The requester would have to state, why the higher limit is needed.
2. Meraki: Can accept or decline the request.
   1. There might be a better way instead of using 1000 of requests -> e.g. action batches
   2. If there isn't a better way (yet): Increase the api limit for this organization.
      1. In the backend Meraki could improve the api in a way to reduce the number of api calls.
         e.g. for the Snapshot API: Offline Snapshots -> ask the cameras directly via oauth/token/... for a specific image.

P.S.:

I've also opened a new PR to increase the asyncio limit for concurrent requests.

[Alisdair85]

Hey @Philip, I have the same challenge and take the same approach as you re multi-Orgs but its not scalable to operate/manage as efficiently, more so if its a managed service offering. Maybe Meraki could look at bundling in an "API quantity enhancement" to the MV Sense license as today you don't get a whole heap with the MV Sense license, more so as I've seen a pivot in the last year away from it and a preference to do RTSP image process which doesn't require MV Sense license but does introduce compute and architecture complexities

Though guess with this current workaround approach you are getting 10 FoC licenses for each Org, which in turn is a revenue reducer for Partner and Vendor which I would have thought they would want to address with a scaling offering 

[PhilipDAth]

You are correct @Alisdair85 - I've actually stopped selling MV Sense licences because using lots of orgs means I don't need my customers to buy them anymore (since you get 10 free licences per org).

The API limit is actually causing a revenue reduction for Meraki.

@Greenberet is right - changing the snapshot API so you could get the snapshots directly from the camera would change things.

However I was using a local MQTT server for doing processing, but because of how the API restriction worked and being forced to work around that, I'm now using a cloud-based MQTT server and have stopped having any compute on-premise anymore.

[AlexanderN]

That is wonderful!

I would like to highlight that 36,000 API calls per hour is so much higher when compared to our competitors like MIst with 5,000 API calls per hour  (limited by and dependent on AWS) and Aruba 42 API calls per hour (1000 calls per day) (playing catch-up with a super limited number of API endpoints).

Meraki continues to lead the way with the API-first approach with others are still lagging behind 🙂 

[Austin_Campbell]

The solution to this issue is simple. All meraki api calls have a built in header named 'Retry-After':. In your api requests simply put in the number of seconds you want it to wait before it sends the next request. I typically use 3 seconds. This bypasses any request limit or timeout. I use this method on all of my python scripts and I am able to iterate through all of my networks and make hundreds of api calls in rapid succession to make mass changes. There are limits to using only API calls to complete networking tasks. Combining them with scripts is where they shine. 

[PhilipDAth]

>The solution to this issue is simple. All meraki api calls have a built in header named 'Retry-After':. In your api requests simply put in the number of seconds you want it to wait before it sends the next request.

This solution won't work for the case I have given.

Let's say you've slowly been rolling our Meraki cameras to your drive-throughs, and it has no reached the point where you are averaging 20 vehicles per second going through your drive-throughs across all your branches.  To process the number plates you need to now call the API generateSnapshot 20 times per second.

You are constrained to 10 calls per second.

After the first second, you use your method and back off for say 1 second.  Now you need to retrieve the 10 snapshots you couldn't get in the first second, plus 20 more for the current second - so you need to make 30 API calls.

If you keep delaying and retrying you will experience an exponential failure.  Delaying makes the issue worse.

[John_on_API]

That's a good point. Isn't the real limiter here the endpoint itself, rather than the rate limit? One can imagine an snapshot endpoint that can generate multiple snapshots in a single call. That'd be a lot more efficient.

[John_on_API]

This is now rolled out to all customers, including Meraki China.

[PhilipDAth]

> One can imagine an snapshot endpoint that can generate multiple snapshots in a single call

Hmm.  The camera sees a vehicle, tells you about it, and then you make an API request for an image.

You would only be able to request multiple snapshots if you had a waiting queue and then combined all the requests into one.  Doable.