Could someone explain…
- Running JMeter 5.6 with 25 concurrent threads against POST /api/v2/security/users to validate user creation throughput for a new onboarding batch process.
- Getting immediate 429 Too Many Requests errors on US1 environment.
- The error response body contains: {“errors”:[{“code”:“too_many_requests”,“message”:“Rate limit exceeded”}]}.
- Need to understand the specific rate limit for this endpoint. Documentation mentions general API limits but not specific per-endpoint values for security resources.
- Testing from America/New_York timezone during EST business hours.
- Using valid OAuth2 access token with required scopes: admin:security:users:write.
- Request payload includes basic user attributes: name, email, and role IDs. No complex objects.
- Previous tests with lower concurrency (10 threads) succeeded without errors.
- Increasing concurrency beyond 15 threads triggers immediate 429 responses.
- Want to validate if this is a hard limit for security APIs or if configuration options exist to increase throughput.
- Checking if WebSocket connections or other API calls in the same tenant are contributing to the rate limit calculation.
- Monitoring tenant API usage via Admin Dashboard shows low overall utilization during test window.
- Question is whether security endpoints have stricter rate limits than standard configuration APIs.
- Looking for best practices to structure load tests for user provisioning without hitting rate limits.
- Considering adding delay between requests in JMeter but want to understand the actual limit first.
- Any guidance on rate limit tiers for security vs. configuration APIs would be helpful.
- Previous experience with WFM and Dialer APIs showed consistent 429s at similar concurrency levels.
- Assuming pattern holds for Security APIs but need confirmation.
- Testing against production-like environment to validate capacity planning assumptions.
- Goal is to determine maximum sustainable user creation rate for bulk operations.
- Appreciate any insights from team members familiar with security API rate limiting behavior.