How do I deal with API rate limiting?

[SiDawg]

We have about 6000 pages to create: I'm currently doing tests in batches of about 100 to get our format right etc. I noticed the other day the rate went from a page a second to a page every 6 seconds or so... not sure if that was load (US traffic waking up towards my AU evening) or auto rate limiting

I saw somewhere that we should do our own rate limiting to 1 request every 10 seconds otherwise we might be banned !?

What's the most up to date advice on this, are there any exceptions made, or should we just make sure to implement the 10 second rate to avoid issues?

[Neil]

Hi @SiDawg There is some developer documentation on rate limiting on Confluence Cloud APIs:

https://developer.atlassian.com/cloud/confluence/rate-limiting/

You'll find info on limit detection, retries, and request backoff strategies.

[SiDawg]

Thanks. It's a little confusing: is the rate limit enforced? I read somewhere else that its up to me to ensure i dont send more than 10 requests a minute, but then the page you sent suggests I can send what i like but the API may respond with 429 error?

I guess i'm wanting to primarily make sure I won't be banned: I'm happy to add rate limiting wait code if i need to, but if the API will response with an error that is preferable then it will run "full speed" unless it has a reason not to and I can leave it for your server to tell me?

[Neil]

Hi @SiDawg The cost-based rate limiting (as discussed on that page I shared) has been published for some time now (at least a few years). If you're being rate limited, you should be seeing 429 responses. 

Is this your own app/client making calls against your own instance, or are you making an abundance of calls across many instances (ex: you have an app in the Marketplace)? 

As for getting banned.. there definitely isn't anything published on the page about that. That being said, if your app is sending requests that might resemble the magnitude of a denial service attack, I would imagine that mitigation measures might kick in. 

So yes, I would recommend that your app has a strategy for when it encounters 429 errors.