What’s the best way to handle rate limiting when scaling outbound campaign creation through the platform api? i am running jmeter scripts from our singapore office to simulate high-volume campaign launches. the goal is to test the system’s capacity for concurrent campaign updates, but we are hitting walls immediately.
we are using a service account with outbound:campaign:write and outbound:campaign:read scopes. the jmeter thread group is set to 50 concurrent users, each executing a simple put request to /api/v2/outbound/campaigns/{campaignId}. the payload is minimal, just toggling the paused state to simulate a rapid pause/resume scenario across multiple campaigns.
the issue is that after about 10-15 seconds, we start receiving 429 too many requests errors. the response headers include retry-after: 5, but even spacing the requests with a 5-second constant timer doesn’t fully resolve the issue under higher thread counts. when we increase the threads to 100, the error rate spikes to nearly 80% within the first minute.
i have checked the api documentation, but the rate limits for outbound endpoints are not explicitly detailed in terms of requests per second per tenant or per user. are there specific limits for the campaign management endpoints that i am missing? also, is there a recommended pattern for retrying these requests in a load testing scenario without triggering a cascade of failures?
we are not seeing any issues with the actual dialing capacity or websocket connections, which leads me to believe this is purely an api throttling issue. i have also verified that the service account is not hitting any global tenant-level limits that would affect other operations.
any insights into the expected throughput for these endpoints or best practices for structuring the jmeter script to respect the rate limits would be greatly appreciated. we need to ensure our load tests accurately reflect real-world usage patterns without being artificially capped by api throttling.