I’ve spent hours trying to figure out why the Genesys Cloud Telephony API returns SIP 486 Busy Here responses when concurrent call initiation attempts exceed 200 requests per minute. The environment is Genesys Cloud US1. The load testing tool is JMeter 5.6. The goal is to validate system capacity for peak inbound call volumes during holiday seasons. The test script simulates outbound calls via the POST /api/v2/telephony/providers/edges/calls endpoint. Each request includes valid JWT authentication tokens generated via the OAuth client credentials flow. The Architect flow is configured to route calls to a specific queue with a maximum capacity of 50 concurrent agents. The flow logic includes a simple delay of 2 seconds before connecting to the agent. When the JMeter thread group ramps up to 100 virtual users making calls every 3 seconds, approximately 15% of the requests fail with a 486 status code. The error message in the response body indicates “Call rejected by destination”. The queue configuration shows no overflow settings. The edge cluster health dashboard reports normal CPU and memory utilization. The WebSocket connection pool in JMeter is set to 200 connections. The API rate limit headers show that the request count is well below the documented threshold of 100 requests per second for this endpoint. According to the Genesys Docs, the 486 error usually indicates that the called party is busy. However, the agents are idle in the simulation. The call logs in Genesys Cloud show that the calls are being created but immediately terminated. The latency for the API response is under 100ms for successful calls. The failing calls also have low latency. This suggests that the rejection is happening at the routing level rather than due to network issues. The test environment uses a dedicated edge cluster for load testing. The SIP trunk capacity is configured for 1000 concurrent calls. The issue persists even when reducing the concurrent user count to 50. The error rate increases proportionally with the request volume. The JMeter logs do not show any connection timeouts. The OAuth token refresh mechanism is working correctly. The question is whether there is a hidden limit on call creation rates per user or per edge cluster. The documentation does not specify a per-minute limit for outbound call initiation. The support ticket system suggests checking the queue capacity, but the agents are available. The test script includes proper error handling for 429 and 503 errors. The 486 error is not handled in the standard retry logic. The goal is to understand the root cause of the 486 errors under load. The expectation is that the system should handle the configured queue capacity without rejecting calls when agents are idle. The current behavior suggests a bottleneck in the call routing logic. The next step is to analyze the detailed call flow logs. The logs are available in the Genesys Cloud admin console. The analysis will focus on the timestamp of the rejection. The correlation with the JMeter thread start time will be checked. The result will determine if the issue is related to concurrency limits or configuration errors. The hope is to find a solution that allows for accurate capacity planning. The alternative is to reduce the test volume, which defeats the purpose of the load test. The community input is requested to identify any known limitations or best practices for high-volume outbound call testing. The specific version of the Genesys Cloud platform is not explicitly stated in the UI, but the API version is v2. The JMeter plugin version is 1.0.1. The operating system for the JMeter server is Ubuntu 20.04. The Java version is 11. The network connection is stable with low packet loss. The DNS resolution is fast. The SSL handshake is successful. The overall infrastructure is stable. The issue is isolated to the call creation API. The other APIs like user management and reporting are functioning correctly. The load test is scheduled to run daily. The failure rate is consistent across different days. The time of day does not seem to affect the error rate. The timezone is America/New_York. The test runs during business hours. The agent availability is simulated using the presence API. The presence status is set to Available. The queue skill is correctly assigned. The routing strategy is set to Longest Available Agent. The timeout settings are default. The retry logic is disabled for this test. The expectation is clear routing. The reality is frequent rejections. The gap needs to be closed. The question remains: what is triggering the 486 error?