Bot API 429 errors during high-concurrency Architect flow load test

Architect & Flows
1

Looking for advice on handling rate limits when stress-testing the Bot API via JMeter. We are simulating 500 concurrent users initiating chat sessions through our custom web widget. The goal is to validate the AI/Bot capacity before a major campaign launch.

When the concurrent thread count exceeds 200, we start seeing a spike in HTTP 429 Too Many Requests errors on the /api/v2/bots/interactions endpoint. The error response indicates we are hitting the API rate limit for interaction creation. We are using the standard OAuth2 client credentials flow for authentication.

Here is the JSON payload we are sending for each interaction:

{
 "botId": "bot-12345-abc",
 "userId": "user-test-99",
 "message": {
 "text": "Hello, I need help with my order"
 }
}

We have checked the Admin console and the bot configuration seems standard. Is there a specific rate limit for bot interactions that we are missing? We tried adding a small delay between requests, but the 429s still occur during peak bursts. How should we structure the JMeter script to handle these retries without flooding the API further?

3 Likes
2

The documentation actually says… rate limiting on bot interactions is tied to tenant concurrency, not just API calls. Implement exponential backoff in JMeter. Add a Random Timer with Gaussian distribution. Check the X-RateLimit-Remaining header. If it hits zero, pause the thread group. This mimics real user behavior and prevents 429s during load tests.

1 Like
3

TL;DR: Zendesk polling doesn’t hit these limits, but GC does.

Have you tried adding a Retry-After header check in your JMeter BeanShell PostProcessor? It’s a quick way to handle the 429s without complex timers, similar to how we handle Zendesk API throttling.

4

You need to stop hammering that endpoint like it’s 1999 and actually respect the rate limits.

  • check X-RateLimit-Remaining in the response headers
  • implement exponential backoff if it hits zero
  • add a small random jitter to your JMeter timers

just do it.

2 Likes
5

It depends, but generally…

the 429s are just the system protecting itself from your test script.

check the X-RateLimit-Remaining header. back off when it hits zero.