Hi Team, we are having a bit of trouble with the rate limiting that we have implemented, as we were hitting GoodData endpoints very hardly, but this now is making things to pile up on our side, so I am wondering is there a way to increase the limit on the endpoints on your side? or would this require changing the plan/package or something similar?

Great question! Here's what the knowledge sources say about your situation: API Rate Limits — Options for Increasing Limits GoodData Cloud (SaaS) If you're on GoodData Cloud, the rate limits are managed by GoodData and are not self-configurable. The limits are set globally and enforced via a fixed window strategy. [Rate Limiting] If you believe you've hit rate limits despite following best practices and have a valid use case requiring higher limits, you should contact GoodData Support with: • Your use case description • Current request patterns • Expected request volume • Any relevant technical details GoodData's support team will review your requirements and work with you to find an appropriate solution. This is not necessarily a plan upgrade — it's handled case-by-case by the support/account team. [Rate Limiting] GoodData.CN (Self-hosted) If you're on GoodData.CN (self-hosted), rate limits are fully configurable by your own administrators via Helm chart values. You can directly increase the

limit

parameter in your configuration. [Configure API Rate Limits] In the Meantime — Best Practices to Reduce Pressure While you sort out the limit increase, consider these approaches to reduce the load on your side: • Implement exponential backoff when receiving

429

responses • Respect the

Retry-After

header to avoid unnecessary retries • Cache responses where possible to reduce redundant calls • Batch operations where supported • Distribute requests evenly over time rather than sending bursts [Rate Limiting] Bottom line: Reach out to GoodData Support (or your account owner) with your traffic details. A plan change is not necessarily required — the support team can assess whether a limit adjustment is appropriate for your use case. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

what is the pricing for the self hosted

Hi Jhonatan, I can see in our system that you're currently on our Cloud SaaS product. If you'd like to increase your usage limits, I'd recommend reaching out to your account owner, Tomas Kratochvil, to discuss the available options. Once we receive his approval, we'll be happy to make the necessary adjustments.

hi @Shamil Akhmadyshev, I tried messaging him but he didn't actually respond

Hi Jhonatan, we need to understand your workflow and which endpoint limits we should increase. Could you please give us more details on what you are trying to achieve and how exactly? Thank you.

Hey @Shamil Akhmadyshev I would say our main issues are the limits on User create, User Data Filter endpoints, as at times we can onboard a company with 20k users, and we need to quickly create those users, which would take a long time and jobs pile up with the current rate limiter

Hi Jhonatan, Thank you for sharing these details. Would it be possible to adjust your requests to one of the following workarounds? 1. Serialize or throttle concurrency. Instead of firing all user creation requests in parallel, process them sequentially or with a bounded concurrency (e.g. max 5 at a time with a small delay between batches). 2. Respect the

Retry-After

and rate limit headers. Check

X-RateLimit-Remaining

proactively and back off before hitting 0, not just react to 429s. 3. When a 429 is received, wait

Retry-After

seconds minimum, then retry. Please let us know the result.

Hi Jhonatan, This is Daniela from the Technical Support Team. We’ve checked internally, and unfortunately we’re not able to increase the API rate limits in general. The limits are in place to protect the platform for all customers and can’t be adjusted on a per-tenant basis. The 429 you are seeing, are because you are hitting the platform limits. This can be fixed on your end as mentioned by my colleague Shamil: 1. Throttle concurrency process user creation sequentially or with a small bounded pool (e.g. max 5 parallel requests) with a short delay between batches 2. Check

X-RateLimit-Remaining

proactively and slow down before hitting 0, rather than waiting for a

429

3. On a

429

, wait the full

Retry-After

duration before retrying Also, I would like to understand your use-case a bit better: how frequently do you onboard batches of this size? Is this a recurring event, a one-time migration, or something that happens unpredictably? That context will help us advise you better. Thanks!

The point is, we already have the rate limiting in place, and this is exactly what is causing our requests to pile up, as it takes too long to process it, given we can't increase limits, we'd have to evaluate the self hosted option

If I understand correctly, the 20k is because the requests pile up? May I know how often you do this onboarding? and why? Please, the more details we have about your use case the better we can help you. Regarding self-hosted: we understand you’re evaluating that option, but given the pricing tier it starts at, we want to make sure these alternatives are fully explored first before you invest time in that direction.