Best practices for handling API rate limits and implementing retry mechanisms

I’m dealing with API rate limiting in my application and looking for established patterns to handle this effectively. Currently, my retry mechanism implementation feels messy and difficult to maintain.

Questions:

  1. What are the recommended best practices for handling API rate limits in production applications?
  2. How should retry mechanisms be implemented to handle rate limit responses efficiently?
  3. Are there any well-tested libraries or patterns that handle this elegantly?

Current approach: I’m currently implementing my own retry logic, but it’s becoming increasingly complex and hard to maintain.

Hello there @ethanolle1,

We have our article about rate limits here :smile:

We do not have a specific recommendation on how to handle the API limits other than what is exposed there.

You can avoid hitting the limit using a mechanism that checks your available quota. Then you can use your own retry mechanism for when you do hit the limit.

We do not have specific libraries recommended by monday’s team, but maybe some other user has a suggestion :crossed_fingers:

Cheers,
Matias

@Matias.Monday
We are also stuck with the API rate limit(mutations allowed per minute).

Is there any way like a query, etc using which we can get how many allowed mutations are left for that particular minute.

For e.g, the Other plan tier which allows 100 mutations per minute(see it here). An name X app made like 40 mutation at 11:00, and in the same one minute window our app needs to perform 80 mutation, then the 20 mutation will fail and we need to retry it again. Instead of retrying, we are looking for a way that we can get how many mutations are left, and then we can perform that many mutations only for that one minute window?

Thanks

The minute limits are per app (per account) - not per account. That means your app (assuming its a marketplace app) is not sharing with other apps. You get the full 100.

1 Like